[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Peter Antman wrote:

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

What would the tradof/effect be of having (focus on Corba):

a) 20 000 XmlBlaster connections with one subscription each (same VM),
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

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
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,