excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@managesoft.com>
Subject Re: Latest version of Fortress?
Date Fri, 05 Nov 2004 16:17:24 GMT
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


Mime
View raw message