You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Marcus Crafter <cr...@managesoft.com> on 2004/10/19 17:36:41 UTC
Latest version of Fortress?
Hi All,
Hope all is going well.
Was just wondering, what is actually the latest version of Fortress - it
seems like the project.xml refers to a version 1.2, however on
apache.org/dist/avalon/avalon-fortress/jars there's only 1.1.
Has 1.2 been released? If not is there anything holding it back?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Leo Simons <ls...@jicarilla.org>.
Berin Loritsch wrote:
> 1.2 has not been released. I believe we haven't done so in order to
> ensure everything still works after the switch to D-Haven event.
Hmm. I believe we're short of hands to do much of the neccessary work atm.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: ThreadManager.dispose() issue
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Peter,
Marcus Crafter wrote:
> Thanks for that information - didn't realize there were other issues in
> that space as well that people knew about.
>
> I'll take a look at the spice threadpool package as you suggested.
>
> Are there also spice equivalents of cornerstone connection and socket
> manager, that already use the thread manager you mention?
Found it - spice netserve. Looking into it now. Thanks again for your help.
Cheers,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: ThreadManager.dispose() issue
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Peter,
Thanks for that information - didn't realize there were other issues in
that space as well that people knew about.
I'll take a look at the spice threadpool package as you suggested.
Are there also spice equivalents of cornerstone connection and socket
manager, that already use the thread manager you mention?
Cheers,
Marcus
Peter Donald wrote:
> Hi,
>
> Marcus Crafter wrote:
>
>>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 :)
>
>
> I know it may not be much help but that code has many many many
> threading/synchronization issues and breaks in a whole range of
> environments. It was actually the motivation to create Spice-ThreadPool
> (http://spice.codehaus.org/threadpool/index.html) which has far more
> unit tests with much better coverage (~90% IIRC). I would highly
> recomend you dump the ThreadManager or if you can not due to legacy apps
> then make an adapter around the Spice-Threadpool code.
>
> Cheers,
>
> Peter Donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: ThreadManager.dispose() issue
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
Marcus Crafter wrote:
> 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 :)
I know it may not be much help but that code has many many many
threading/synchronization issues and breaks in a whole range of
environments. It was actually the motivation to create Spice-ThreadPool
(http://spice.codehaus.org/threadpool/index.html) which has far more
unit tests with much better coverage (~90% IIRC). I would highly
recomend you dump the ThreadManager or if you can not due to legacy apps
then make an adapter around the Spice-Threadpool code.
Cheers,
Peter Donald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
ThreadManager.dispose() issue
Posted by Marcus Crafter <cr...@managesoft.com>.
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Berin Loritsch <bl...@d-haven.org>.
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.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Marcus Crafter <cr...@managesoft.com>.
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:
DEBUG 2004-11-05 17:59:26.038 [managesoft ] (): Shutting
down:
org.apache.avalon.fortress.impl.handler.LEAwareComponentHandler@12a73d9
[org.apache.avalon.fortress.impl.handler.ThreadSafeComponentHandler[for:
org.apache.avalon.cornerstone.blocks.threads.DefaultThreadManager]]
DEBUG 2004-11-05 17:59:26.038 [managesoft.thread-manage] (): "default
Worker #1" (in main) : destroying.
DEBUG 2004-11-05 17:59:26.038 [managesoft.thread-manage] (): "default
Worker #1" (in main) : destroyed.
...<snip/>...
DEBUG 2004-11-05 17:59:26.048 [managesoft ] (): Shutting
down: org.apache.avalon.excalibur.logger.LogKitLoggerManager@ad157f
DEBUG 2004-11-05 17:59:26.041 [managesoft.thread-manage] (): "default
Worker #1" (in default Worker #1) : notified.
DEBUG 2004-11-05 18:03:39.867 [managesoft.thread-manage] (): "default
Worker #1" (in default Worker #1) : stopped.
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?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Berin, all,
Berin Loritsch wrote:
> Marcus Crafter wrote:
>>>> Has 1.2 been released? If not is there anything holding it back?
>>>
>>> 1.2 has not been released. I believe we haven't done so in order to
>>> ensure everything still works after the switch to D-Haven event.
>>
>> Ok, is that the only thing holding us back? I presume all of the test
>> cases, and everything still works right? Is it just real-world testing
>> that needs to be done?
>
> Right, and then the work of packaging it up and "shipping" it.
>
> It still works with my GUIApp stuff... But mileage may vary.
Ok. I've updated to the latest version of Fortress, and Cornerstone and
are seeing some thread related problems when running our test cases. We
were seeing these issues before the update though, so they're not
new/introduced.
We've got an application, Fortress based, that uses Cornerstone
connection/thread/socket manager components to offer a service on a
certain port.
We've got around 20/30 test cases for our our components, each of them
using their own container via setUp()/tearDown().
(ie. before each test* method starts, a container is created, the test
method is run and then the container is shutdown).
Running each individual test case works fine, but running them in a
suite (ie. inside one JVM), results in the following three phenomena:
* "Socket is closed" exceptions from time to time
* "Cannot get a component from a disposed handler" exceptions
* [FATAL ERROR] Writing event to closed stream.
The "Socket is closed" exception:
ERROR 2004-11-04 18:51:02.861 [managesoft.connection-ma] (): Exception
accepting connection
java.net.SocketException: Socket is closed
at java.net.ServerSocket.accept(ServerSocket.java:415)
at
org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:105)
at
org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55)
at
org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116)
ERROR 2004-11-04 18:51:02.862 [managesoft.connection-ma] (): Exception
accepting connection
is coming from within Cornerstone connection, occurs every couple of
test runs. When this occurs, it prints this exception many many times
before the test case ends.
The 'Cannot get a component...' exception is:
org.apache.avalon.framework.service.ServiceException: Could not return a
reference to the Component
(Key='org.apache.avalon.cornerstone.services.threads.ThreadManager')
at
org.apache.avalon.fortress.impl.lookup.FortressServiceManager.lookup(FortressServiceManager.java:117)
at
org.apache.avalon.cornerstone.blocks.connection.DefaultConnectionManager.service(DefaultConnectionManager.java:53)
at
my.fancy.server.ConnectionManager.service(ConnectionManager.java:59)
at
org.apache.avalon.framework.container.ContainerUtil.service(ContainerUtil.java:143)
at
org.apache.avalon.fortress.impl.handler.ComponentFactory.serviceComponent(ComponentFactory.java:343)
at
org.apache.avalon.fortress.impl.handler.ComponentFactory.newInstance(ComponentFactory.java:178)
at
org.apache.avalon.fortress.impl.factory.NoopObjectFactory.newInstance(NoopObjectFactory.java:38)
at
org.apache.avalon.fortress.impl.handler.AbstractComponentHandler.newComponent(AbstractComponentHandler.java:246)
at
org.apache.avalon.fortress.impl.handler.ThreadSafeComponentHandler.doPrepare(ThreadSafeComponentHandler.java:40)
(full stacktrace attached)
This one happens, even though I've specified that our
'ConnectionManager' component has a dependency to the cornerstone
'ThreadManager' component, and I can verify in the logs that the
ThreadManager is started before the connection manager.
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.
The interesting thing is that the first 2 problems disappear when I
change the component activation policies to 'inline' rather than leaving
them as their default 'background', which seems to me to be a threading
related issue?
I've looked at the code with different tools, looking for statics left
set, disposables not disposed, and the like, but haven't really found
anything conclusively wrong.
What do you think about these issues? Any ideas about where to look? Has
anyone else perhaps seen these as well?
Cheers,
Marcus
Re: Latest version of Fortress?
Posted by Berin Loritsch <bl...@d-haven.org>.
Marcus Crafter wrote:
> This time a bit slower on the shift-enter :)
>
> On Tue, 2004-10-19 at 19:32, Berin Loritsch wrote:
>
>>Marcus Crafter wrote:
>>
>>>Has 1.2 been released? If not is there anything holding it back?
>>>
>>>Cheers,
>>>
>>>Marcus
>>>
>>
>>1.2 has not been released. I believe we haven't done so in order to
>>ensure everything still works after the switch to D-Haven event.
>
>
> Ok, is that the only thing holding us back? I presume all of the test
> cases, and everything still works right? Is it just real-world testing
> that needs to be done?
>
Right, and then the work of packaging it up and "shipping" it.
It still works with my GUIApp stuff... But mileage may vary.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Marcus Crafter <cr...@managesoft.com>.
This time a bit slower on the shift-enter :)
On Tue, 2004-10-19 at 19:32, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >
> > Has 1.2 been released? If not is there anything holding it back?
> >
> > Cheers,
> >
> > Marcus
> >
>
> 1.2 has not been released. I believe we haven't done so in order to
> ensure everything still works after the switch to D-Haven event.
Ok, is that the only thing holding us back? I presume all of the test
cases, and everything still works right? Is it just real-world testing
that needs to be done?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Marcus Crafter <cr...@managesoft.com>.
On Tue, 2004-10-19 at 19:32, Berin Loritsch wrote:
> Marcus Crafter wrote:
>
> > Has 1.2 been released? If not is there anything holding it back?
> >
> > Cheers,
> >
> > Marcus
> >
>
> 1.2 has not been released. I believe we haven't done so in order to
> ensure everything still works after the switch to D-Haven event.
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Latest version of Fortress?
Posted by Berin Loritsch <bl...@d-haven.org>.
Marcus Crafter wrote:
> Hi All,
>
> Hope all is going well.
>
> Was just wondering, what is actually the latest version of Fortress - it
> seems like the project.xml refers to a version 1.2, however on
> apache.org/dist/avalon/avalon-fortress/jars there's only 1.1.
>
> Has 1.2 been released? If not is there anything holding it back?
>
> Cheers,
>
> Marcus
>
1.2 has not been released. I believe we haven't done so in order to
ensure everything still works after the switch to D-Haven event.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/