Multiple ProxySubscriberCached for same topic share a cache?
'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
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.
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
ProxySubscriberCachedto 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.
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.
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