[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Reconnected xml-rpc callbacks result in duplicate messages
Brad Clements wrote:
I've been googling for an answer to this problem, and I'm wondering what's the best
way to handle this.if you subscribe multiple times, only one is considered.
I'm using Python and pyBlaster.py to subscribe an xml-rpc server for callbacks.
My xml-rpc server keeps track of pings from the server, and if it doesn't get any for a
while it will re-login and re-subscribe to one key.
Also, I'm running my server under DaemonTools, so if it dies, daemontools will restart
It seems that if my server gets restarted, xml-blaster sees it as a new login (but with the
same callback information). It then sends two messages where I expect only one.
And, if I restart my server again, then I'll get 3 messages and so on.
I know this is a hard problem for xmlblaster to deal with, especially since I can
subscribe on behalf of another callback listener, so how's xmlblaster supposed to know
what to do?
xmlblaster thinks my server is still logged in (because the client doesn't get the chance
to logout in this particular case), and the client subscribes to the same key every time.
So, there's two things I need to do:
1. stop multiple duplicate messages
I've been going through the reference guide, and finding a complete list of QoS
parameters is hard.
I know I whined about this last year (sorry), but it sure would be nice to have a
complete QoS list on one page in the docs.
And, having Docs not in a frame would make it easier to bookmark.
Anyway, I found
if you publish several identical messages on the same topic you only
will get the first update of them (not really what you want here).
Which of these is better to use in my situation? I only ever want one copy of any single
message. I think multiSubscribe=false is the better choice, but neither option mentions
the other one and under what conditions I'd pick one over the other.
2. Cleanup the old logins to avoid resource exhaustion
don't need to do that (see below)
my server logs in, subscribes and makes no further requests on the client connection.
So, it's sessionTimeout = 0Yes there is:
I login with the same userid every time. Is there any way I can say "hey, only one login
allowed at a time and each new login will logout the previous instance and clear it's
maxSessions=1 in the conntectQos, however I believe you would do better
here to use persistent subscriptions and avoid to re-subscribe, see
and don't forget to use positive sessionId, that way you make sure to
regain the same session and not a new one.
Ah, looks like <session timeout="0" clearSessions="true" /> is what I want here.