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

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



On Wed, 2003-10-01 at 00:40, Marcel Ruff wrote:
> Marcel Ruff wrote:
> 
> >>> As soon as the Global is recycled all resources (like threads)
> >>> are freed.
> >>> If not to depend on the garbage collector you
> >>> can explicitly call
> >>>
> >>>    glob.shutdown();
> Peter,
> 
> i have now added glob.shutdown() to xmlBlasterAccess.disconnect()
> to be independent of the JVM garbage collector.
> 
> I have played with a profiler tool to verify that
> there is no thread or memory leak.
> 
> Global is receycable, you can use it after a shutdown()
> again to make a new XmlBlasterAccess connection.
> 
> The new code is in cvs,

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

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