Re: [xmlblaster-devel] Socket test with thread leak?

[Marcel Ruff <mr at marcelruff.info>]

> Thats great: the thread leakage seems to have disapeared.
>
> But I also must say, now that I have been playing around with thread
> tests: the client side of XmlBlaster simply created a HUGE number of
> threads. Here's some metric:
>
> 	    Number of thread/connection
> 		IOR	LOCAL
> Only publish	5	4
> Subscriber	14-19	5

I have changed the code to do lazy instantiation (see cvs) and
now on Java client side there is only the Callback socket thread left with
the SOCKET protocol, try this

--------------------------------------
java org.xmlBlaster.Main

java HelloWorld4 -protocol SOCKET
                 -dispatch/connection/pingInterval 0
                 -dispatch/connection/burstMode/collectTime 0

killall -3 java
--------------------------------------


Shows only one thread for SOCKET for the callback server.
For the LOCAL protocol you can set these options
permanent with Address.java (see ConnectQos.java)
when connecting. The LOCAL protocol does not need to
ping or use the burst mode, and it does not need to queue
(so no XmlBlaster.BurstmodeTimer, XmlBlaster.PingTimer
or XmlBlaster.DeliveryWorkerPool threads anymore).

For CORBA you can reduce the pool sizes in jacorb.properties
(in xmlBlaster.jar) on client side, e.g.

  jacorb.poa.thread_pool_min=0

instead of default 5 will reduce the IOR threads from 9 to 4!


Here the new metric:
--------------------------------------
 Number of thread/connection
                IOR     SOCKET  XMLRPC
 Only publish	1       1       0
 Subscriber     9(4)    1       2
--------------------------------------

(note that if you use HSQLDB for persistent queues this
will consume one more thread).

I wonder why your use case requires thousands of clients
in the same JVM, couldn't you solve this with one client
and thousands subscribes?

cu,

Marcel


> For scenarios running XmlBlaster embedded in applications that both
> publish and subscribe this sets a pretty low limit on the number of
> connections. More than 50 IOR connections is not possible, and somewhere
> around 150-200 local connections. 
>
> Here are all the threads created by ONE IOR connection:
>
>  Thread: XmlBlaster.DeliveryWorkerPool.client/Joe-01065010526111 
> Priority: 5 Daemon
>         Thread: XmlBlaster.DeliveryWorkerPool.client/Joe-01065010526111 
> Priority: 5 Daemon
>         Thread: XmlBlaster.BurstmodeTimer  Priority: 5 Daemon
>         Thread: XmlBlaster.CbPingTimer  Priority: 5 Daemon
>         Thread: Thread-6  Priority: 5 Daemon
>         Thread: RequestController-2  Priority: 8 Daemon
>         Thread: Thread-7  Priority: 5 Daemon
>         Thread: Thread-9  Priority: 5 Daemon
>         Thread: RequestProcessor-6  Priority: 8 Daemon
>         Thread: RequestProcessor-7  Priority: 8 Daemon
>         Thread: RequestProcessor-8  Priority: 8 Daemon
>         Thread: RequestProcessor-9  Priority: 8 Daemon
>         Thread: RequestProcessor-10  Priority: 8 Daemon
>             Thread: file:/home/pra/tmp/clientJoe-01065010526111 
> Priority: 5
>
> And here's with LOCAL:
>         Thread: XmlBlaster.DeliveryWorkerPool.client/Joe-01065010911472 
> Priority: 5 Daemon
>         Thread: XmlBlaster.DeliveryWorkerPool.client/Joe-01065010911472 
> Priority: 5 Daemon
>         Thread: XmlBlaster.BurstmodeTimer  Priority: 5 Daemon
>         Thread: XmlBlaster.CbPingTimer  Priority: 5 Daemon
>         Thread: file:/home/pra/tmp/clientJoe-01065010911472  Priority: 5
>
> Is there any way to set up an enviroment where threads are reused for
> more than one client connection?
>
> //Peter
>
> > regards,
> >
> > Marcel
> >
> > --
> > http://www.xmlBlaster.org


--
http://www.xmlBlaster.org