Skip to content

Event PubSub topics + linear filtering.#18266

Merged
tiborvass merged 2 commits intomoby:masterfrom
calavera:events_pub_sub
Dec 3, 2015
Merged

Event PubSub topics + linear filtering.#18266
tiborvass merged 2 commits intomoby:masterfrom
calavera:events_pub_sub

Conversation

@calavera
Copy link
Contributor

Although these two changes could go separatedly, I rather put them together because they are very related. Our filtering system is very inneficient at matching results. This can slow down the events API with complicated filters. Moreover, that API performs operations in linear complexity at best, and exponencial at worst, when we can do constant time at best and linear at worst.

I separated both commits and wrote explanation of the changes in each of them, but I'm copying both messages here for easy reading:

Add PubSub topics.

A TopicFunc is an interface to let the pubisher decide whether it needs to
send a message to a subscriber or not. It returns true if the publisher
must send the message and false otherwise.

Users of the pubsub package can create a subscriber with a topic function
by calling `pubsub.SubscribeTopic`.

Message delivery has also been modified to use concurrent channels per
subscriber. That way, topic verification and message delivery is not o(N+M)
anymore, based on the number of subscribers and topic verification
complexity.

Using pubsub topics, the API stops controlling the message delivery,
delegating that function to a topic generated with the filtering provided
by the user. The publisher sends every message to the subscriber if there
is no filter, but the api doesn't have to select messages to return
anymore.
Make filtering a linear operation.

Improves the current filtering implementation complixity. Currently, the
best case is O(N) and worst case O(N^2) for key-value filtering. In the new
implementation, the best case is O(1) and worst case O(N), again for
key-value filtering.

@thaJeztah
Copy link
Member

Nice! Thanks @calavera

@LK4D4
Copy link
Contributor

LK4D4 commented Nov 26, 2015

Didn't know that we have crappy cancel function :/

@calavera calavera force-pushed the events_pub_sub branch 6 times, most recently from 05ca2f0 to 3181618 Compare December 1, 2015 00:18
@calavera
Copy link
Contributor Author

calavera commented Dec 1, 2015

@LK4D4 we can probably change it. That cancel function only calls daemon.events.Evict with the listener as an argument. I think it would be much more clean if we had an Unsubscribe function in the daemon that took the listener.

That way, the events interface in the daemon could be something like:

type eventsBackend interface {
   Subscribe(since, int64, eventFilter filterArgs) ([]interface{}, chan interface{})
   Unsubscribe(listener chan interface{})
}

@calavera calavera force-pushed the events_pub_sub branch 4 times, most recently from 692645b to 9c2d27c Compare December 2, 2015 00:05
@calavera
Copy link
Contributor Author

calavera commented Dec 2, 2015

@LK4D4 that cancel crappy function is gone now 😄 can you take a look?

Improves the current filtering implementation complixity.
Currently, the best case is O(N) and worst case O(N^2) for key-value filtering.
In the new implementation, the best case is O(1) and worst case O(N), again for key-value filtering.

Signed-off-by: David Calavera <david.calavera@gmail.com>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can eliminate else now :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, thanks :)

A TopicFunc is an interface to let the pubisher decide whether it needs
to send a message to a subscriber or not. It returns true if the
publisher must send the message and false otherwise.

Users of the pubsub package can create a subscriber with a topic
function by calling `pubsub.SubscribeTopic`.

Message delivery has also been modified to use concurrent channels per
subscriber. That way, topic verification and message delivery is not
o(N+M) anymore, based on the number of subscribers and topic verification
complexity.

Using pubsub topics, the API stops controlling the message delivery,
delegating that function to a topic generated with the filtering
provided by the user. The publisher sends every message to the
subscriber if there is no filter, but the api doesn't have to select
messages to return anymore.

Signed-off-by: David Calavera <david.calavera@gmail.com>
@LK4D4
Copy link
Contributor

LK4D4 commented Dec 2, 2015

LGTM

2 similar comments
@tonistiigi
Copy link
Member

LGTM

@tiborvass
Copy link
Contributor

LGTM

tiborvass added a commit that referenced this pull request Dec 3, 2015
Event PubSub topics + linear filtering.
@tiborvass tiborvass merged commit 33ab2bb into moby:master Dec 3, 2015
@calavera calavera deleted the events_pub_sub branch December 3, 2015 16:12
@thaJeztah thaJeztah added this to the 1.10 milestone Dec 17, 2015
@twhiteman
Copy link
Contributor

Gah - please be careful - your changing/breaking docker remote API when changing raw API types (which affects docker compose and other tools), and there's been no update to the docs (API or release notes) for this change:
https://github.com/docker/docker/blob/master/docs/reference/api/docker_remote_api_v1.23.md#list-containers

Old remote API format: filters={"exited":["0"]}
New remote API format: filters={"exited":{"0":true}}

@calavera
Copy link
Contributor Author

calavera commented Apr 8, 2016

@twhiteman filters are backwards compatible and the api knows how to deserialize both formats. See https://github.com/docker/engine-api/blob/master/types/filters/parse.go#L93-L115.

Please, feel free to open an issue if you bumped into problems.

@moby moby locked and limited conversation to collaborators Apr 8, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants