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

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



ons 2003-10-01 klockan 19.39 skrev Marcel Ruff:
> > 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
> --------------------------------------

That's great! I will try it next week.
> 
> (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?

I already have that. I have a sbscription pool that partitions the
subscriptions among a few connections. However, my meassurments of
XmlBlaster idicates that it does not handle more than 1000 subscribers
on one connection that well.

With the new thread numbers, and a slightly smaller pool for publishers
(JCA RA) I think we will do ok for quite a heavy load.

//Peter
> 
> 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
-- 
------------------------------------------------------------
Peter Antman	Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se	WWW: http://www.backsource.org
Email: pra at tim.se	 
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------