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
ex.txt.gz
Description: GNU Zip compressed data--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
