Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple ProxySubscriberCached for same topic share a cache? #41

Open
tcassell94 opened this issue Oct 16, 2017 · 4 comments
Open

Multiple ProxySubscriberCached for same topic share a cache? #41

tcassell94 opened this issue Oct 16, 2017 · 4 comments

Comments

@tcassell94
Copy link

tcassell94 commented Oct 16, 2017

'Ello.

It seems when having multiple ProxySubscriberCached objects listening to the same topic, from different states, removing messages from one object's cache removes them also from the other object's cache.

I believe that this is due to the class variables in ProxySubscriberCached not having 'self.' prepended to them, so they are shared amongst all class instances. I see that this sort of makes sense in that it saves on the number of Subscriber objects etc.

Just wondering if all instances of ProxySubscriberCached sharing the same cache is the intended design, and if so, what the other reasons behind that are?

Cheers

@tcassell94
Copy link
Author

I ask because it was my intention to have different states listening to a 'status' type topic, with the states only acting on messages that are important to them, and discarding the others. An obvious workaround would be different topic names, but that would end up being quite cumbersome.

@pschillinger
Copy link
Member

Yes, this is indeed intended. The main idea about the proxies is to avoid the creation of multiple subscribers/publishers/etc. when instantiating states multiple times across a behavior or to bundle access to the same topic in general. Also, to provide a synchronous access to received messages in the "execute" loop of a state instead of having asynchronous callbacks, messages are cached.

However, I see your issue. I think there are two possibilities to address this:

  • Make the states ignore the messages which are not of interest for them, for example by filtering the buffer seen by a state according a given condition, e.g. using filter(...). This would probably rather be a short-term solution.
  • Extend ProxySubscriberCached to allow creation of separate buffers if explicitly asked for. I can help with that if you would like to go this way, but would suggest to start with a modification by you supporting your use case best.

@tcassell94
Copy link
Author

Yeah at the time I came across this I just made a new class called ProxySubscriberIndependentCached, which was a real simple rework of the existing class, in order to have separate queues. This has been working well and still provides the nice functionality of the caching of messages.

@dcconner
Copy link
Member

Any further discussion of this? @pschillinger

@tcassell94 Are you interested in sharing your implementation? If so, please submit a PR to https://github.com/FlexBE/flexbe_behavior_engine

fmessmer added a commit to fmessmer/flexbe_behavior_engine that referenced this issue Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants