Hi Guys,

I think I've tracked down part of the cornerstone threadmanager dispose() issue described in my previous email, but I'm not sure how to handle it - any ideas appreciated :)

Cornerstone thread manager uses at a lower level (via SoftResourceLimitingPool) o.a.a.excalibur.pool.DefaultPool.

When disposing the ThreadManager, it passes on the request to dispose to the underyling thread pool manager, which is below.

The method (in o.a.a.excalibur.pool.DefaultPool):

public final void dispose()
{
    try
    {
        m_mutex.acquire();
        try
        {
            while( m_ready.size() > 0 )
            {
                this.removePoolable( (Poolable)m_ready.remove() );
            }
        }
        finally
        {
            m_mutex.release();
        }
    }
    catch( Exception e )
    {
        if( getLogger().isWarnEnabled() )
        {
            getLogger().warn( "Caught an exception disposing of pool", e );
        }
    }

    this.m_disposed = true;
}

From what I can see there something is missing.

The 'm_ready' field contains the poolables ready to be assigned, however when poolables are in use, they're taken out of the 'm_ready' buffer, and put into an 'm_active' list, until returned (see DefaultPool.get()/put()).

So, if a dispose() comes along while poolables are out in use (and are hence not in the m_ready buffer but in the m_active list) then they are skipped and not disposed.

What do you guys think?

The problem I'm finding is how to actually dispose them properly, since at the level of DefaultPool, we don't even know they're threads.

I added another loop inside the dispose():

    while( m_active.size() > 0 )
    {
        this.removePoolable( (Poolable)m_active.remove( 0 ) );
    }

but that gave me an exception:

[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.032 sec
java.lang.IllegalStateException: Attempted to recycle dead thread.
at org.apache.excalibur.thread.impl.WorkerThread.recycleThread(WorkerThread.java:211)
at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:194)


This seems to be happening simply because the WorkerThread is being disposed() while the run() on the thread is being done. At the end of the run(), a recycle of the thread is attempted - which causes the exception to be thrown due to the dispose() invalidating the state of the WorkerThread.

So for the moment I'm kind-of stuck on how to fix it - any ideas guys?

Cheers,

Marcus



Berin Loritsch wrote:
Marcus Crafter wrote:

Hi All,

Marcus Crafter wrote:


And the last one "[FATAL ERROR] Writing event to closed stream" seems to happen often, but doesn't have any noticable effect on the test case results.


Bit more information on this one.

The error is actually coming from within logkit, and from what I can see is due to:


<snip/>

ie. the LogKitLoggerManager being closed before the Cornerstone ThreadManager has finished shutting down all of the thread pools - and once the logkit manager is shut down, the events are marked as being written to a closed stream.

Should the Cornerstone Thread Manager block until all thread pools have been cleaned up?


It makes sense.


-- ..... ,,$$$$$$$$$, Marcus Crafter ;$' '$$$$: Computer Systems Engineer $: $$$$: ManageSoft Corporation $ o_)$$$: Frankfurt am Main, Germany ;$, _/\ &&:' ' /( &&& \_&&&&' &&&&. &&&&&&&:

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache Excalibur Project -- URL: http://excalibur.apache.org/



Reply via email to