Re: Concurrent sending

[Marcel Ruff <ruff at swand.lake.de>]

Hi Peter,

> Yup. One of the really nice features of xmlBlaster (I think) is the
> ability to sort of do a selection with XPATH in realtime agains XML. But
> since this today only is possible in the key part I en up duplicating my
> xml-messages, on in the key and one in the message body, wich is not
> that effective. And I really do think there is an important domain where
> you do not only want to select on some keys, but on the complete content
> of the message (this is where xmlBlaster shines compared to JMS).

Ok, got it.

For the time being, if you have xml message contents,
you can just place the content in the key.
But be aware, that the big DOM (built from the key meta information)
in xmlBlaster is memory (RAM) based only,
even with the new persistent database from Manuel).

> >> Today I have another question: How should one handle concurrency (and
> >> perhaps pooling) with xmlblaster?
> ...
> I have checked that (I think, is it
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.login.callback.html
> ?)
Yes
> And I do not fully understand how this would solve the problem. If I
> understand correctly, the RFC is about having fallback callbacks, apart
> from the first three lines that talk about session based login.

You are right, the first three lines only cover session based
logins (allowing multiple login sessions with the same user name).
The rest specifies how to handle PtP and Pub/Sub style
with sessions, and other login related 'quality of services'.

> >> Another scenario. I use XmlBlaster in JBoss, and are contemplating
> >> integrating it closer into JBoss and perhaps write a J2EE Connector
> >> provider adapter. The normal way to go in a J2EE application is that you
> >> set up one set of credentials for a bean (say a message-driven bean, or
> >> a stateless bean). This is then used in conjunction with a connection
> >> pool of some sort, that will upphold many connections with the same
> >> credentials.
> >
> > If i remember right, the message driven bean is single threaded,
> > so one connection would do the job.
> > There would be no performance gain even for multi logins in this
> > case, since the client is in the same JVM.
> 
> Both yes and no. Each instance of a message driven bean (or stateless
> session bean for that matter) is single threaded. But for each logical
> bean there may exist many instances of the same bean, serving concurrent
> access.
> 
> Say I have a stateless session bean that want to use xmlBlaster to
> publish something. Following the way one uses JDBC connection or how one
> would use J2EE Connector, you will look up a ConnectionFactory with
> JNDI. Each time you want to do something you use the factory to get a
> connection, wich you will close at the end of the method call. These
> connections should be pooled.
> 
> When you configure your bean you will want to set *one* login name, but
> the bean will serve concurrent accesses, so in any given moment there
> may be more than one bean that holds a connection to xmlBlaster with the
> same credentials.
> 
> Of cource it would be possible for the wrapper to sort oi add an counter
> to the name to get different logins. But, what are the name/pwd for then
> in the first place. If I want security I would have to configure (I
> guess) xmlBlaster to treat joe_1 to joe_n as the same person. Is it even
> possible?

No, every login would create new instances of login handling classes.

> 
> >
> > Having multiple message driven beans, would currently
> > require different login names, or reusing the same
> > login channel.
> >
> > On the other hand, when our above RCF is implemented,
> > you may choose which ever philosophy you like.
> >
> >>
> >> Or is this not possible with xmlblaster? Would I have to have handlers
> >> to the client that is serialized over one login, on one connection?
> >
> > Yep, currently this is a solution (as mentioned above, this
> > would not slow down the overall performance).
> >
> >>
> >> Any help here would be realy good (and may eventually lead to that JBoss
> >> will get MessageDriven beans with built in xmlBlaster support, since I
> >> was the one implementing Message Driven Beans in JBoss ;.))
> > Sounds good, hopefully our mailing list is not that flooded than,
> > like the jboss list :-)
> 
> ;-)
> 
> Another question. How hard do you think it would be to integrate
> xmlBlaster into JBoss as an MBean, that will be configured and started
> in the same runtime/vm as JBoss?

I never had time to look into JMX, but i believe it shouldn't
be this hard to integrate xmlBlaster - i just don't know.
(But it would be a nice thing to have).

I have seen on backsource that you are a Perl hacker as well,
did you ever try a Perl-XmlRpc connection to XmlBlaster?

cu,
Marcel

-- 
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org