Re: [xmlblaster-devel] Connections/CallbackServer/Subscriptions

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

Peter Antman wrote:

> Hi,
> I am sort of tinkering around with a possible subscription pool of a
> sort (a base for implenting Baster MDB:s), but I can not come to grip
> with the tradeoff between having one connection for each subscription or
> one connection for every subscription.
>
> Say this. We have a lot of "clients"/entities who are only subscribing
> on a particular query. Each query is unique. Say we have 20 000 such
> queries/entities/subscriber.
>
> What would the tradof/effect be of having (focus on Corba):
>
> a) 20 000 XmlBlaster connections with one subscription each (same VM),
> or
> b) One XmlBlaster connection with 20 000 subscriptions.
b) has far less memory consumption, but you should definitely write a little
HelloWorld.java trying it!
It is probably a good idea to compare it with the SOCKET protocol,
(or the connectionless XmlRpc or RMI)
it probably handles the situation with less memory footprint.

> For Corba i would guess that the outgoing connection
> (XmlBlasterConnection) is not that important, but it is how the callback
> server works.
>
> With 20 000 connections, is there also 20 000 callback servers
> instantiated?
Yes, on client side there are 20 000 servers active (if it is split to
20 000 clients on many computers it shouldn't be a problem on client side).

On server side, we have a small number object instances per callback doing
the client connection (see protocol/corba/CallbackCorbaDriver.java)

> With 20 000 subscriptions in one connections, does the callback server
> handle that amount of potentail callback invokations?
It definitely should, if there are problems we need to improve the code.

> Would there be anything to gain to create some sort of algoritm that at
> certain breakpoints created a new connection, say we would allow 1000
> subscribers per connection, or (from a corba perspektive) would there be
> absolutely no gain in doing so (the handling of the callback is not
> locked/synchronized in any place, but are totae stateless, so that
> invocatations in the same VM could verry well be handled by only one ans
> the same callback server)?
>
> Hm, hope I made my case clear ;-)
Yes, but you need to test the various setups to have reliable
results, probably we should add your stress tests to the testsuite under
  xmlBlaster/testsuite/src/java/org/xmlBlaster/test/stress
Every test reports some informations like consumed memory per suscribe
or performance issues etc.

It is not a basic task what you are doing - but it will help
xmlBlaster to be more robust,

Marcel

> //Peter
>