Re: [xmlblaster-devel] Reconnected xml-rpc callbacks result in duplicate messages

[Thomas Winningham <winningham at gmail.com>]

Hello,

I joined this list a little bit ago, and I have just a general
question which I can think be *easily* answered considering the
amazing development involved in XML Blaster.

I want to be able to map Ins&Outs of RSS 2.0 XML Document &
metaWeblog.NewPost XML-RPC call... and put some kind of MOM to it.

Here's the RSS 2.0 document spec:
http://blogs.law.harvard.edu/tech/rss

Here's newPost:
http://www.xmlrpc.com/metaWeblogApi

As you can see, the great majority of the two things are in fact the
same. The XML-RPC has some user access stuff, which I intend to tie to
LDAP, and the RSS has some scheduling information and binary
attachment-like-links, which no doubt, probably exists in XML Blaster.

Again, given the intimacy between the greater XML community and these
two technologies in assisting XML's adaption, it sure does seem like
this is too big of an email to ask about this.

I'm wondering if someone can point me in the right direction, or at
least comment in some fashion about this. This would be of great
service I think to the growing blogging community.


Thank you,

Thomas



On Tue, 22 Feb 2005 01:04:57 +0100, Marcel Ruff <mr at marcelruff.info> wrote:
> Michele wrote:
> > Hi Brad,
> >
> > 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.
> >>
> >> 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.
> >>
> >> 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.
> 
> Yes, you can work around this by opening the frame in a new tab or window
> and then bookmark only the frame.
> Michele has designed a new frameless xmlBlaster homepage,
> but hadn't time to do the last little issues.
> Sooner or later the new homepage will pop up.
> 
> >>
> >> Anyway, I found
> >>
> >> qos.subscribe.multiSubscribe
> >>
> > if you subscribe multiple times, only one is considered.
> 
> It works well for EXACT subscribes and XPATH subscribes.
> If the later subscribe contains another subscriber-filter
> setting, this new filter will be used for future messages
> (the subscription is reconfigured)
> (see mime based filtering using the message content like for example REGEX).
> 
> One drawback for some situations could be that the first
> unSubscribe() will remove ALL previous subscribes at once.
> Probably we should add a future flag to switch on/off reference counting
> so that the same amount of unSubscribe() calls is needed as subsribe() calls
> before.
> 
> I think you should use multiSubscribe in your case.
> 
> >
> >> and
> >>
> >> qos.subscribe.duplicateUpdates
> >
> >
> > 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).
> 
> No, it is like that:
> duplicateUpdates=false will suppress duplicate subscriptions
> but it will work only for EXACT oid subscribes.
> This setting has a reference counting, you need as many
> unSubscribe() calls as the subscribe() calls before.
> I would like to set this setting to deprecated and remove
> it in a future version as it 'multiSubscribe' has more functionality
> and is specific for each subscribe() where as duplicateUpdates is
> a general setting for the connection.
> 
> 
> >
> >>
> >> 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 = 0
> >>
> >> 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 callback". ?
> >>
> > Yes there is:
> > maxSessions=1 in the conntectQos, however I believe you would do better
> > here to use persistent subscriptions and avoid to re-subscribe, see
> >
> > http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.persistence.subscription.html
> >
> >
> > and don't forget to use positive sessionId, that way you make sure to
> > regain the same session and not a new one.
> 
> For example login as 'joe/1', that is use always the same
> public session id '1' and your above settings and you should always
> reconnect to the same server session.
> 
> >
> >> Ah, looks like <session timeout="0" clearSessions="true" />  is what I
> >> want here.
> >>
> >> Yes?
> 
> Marcel
> 
> --
> http://www.xmlBlaster.org
>