Re: TestPojoEndpointBase failing on trunk
On 22/02/2015 22:29, Jeremy Boynes wrote: There are still some strange failures on Gump that I don't understand at all. Any help investigating those would be much appreciated. Thanks, this one is passing now. However, I’m seeing some other tests failing: test: [concat] Testsuites with skipped tests: [concat] TEST-org.apache.catalina.connector.TestRequest.NIO.txt [concat] TEST-org.apache.el.parser.TestELParser.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestCustomSsl.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestSsl.NIO.txt [concat] TEST-org.apache.tomcat.util.net.jsse.openssl.TestCipher.NIO.txt [concat] TEST-org.apache.tomcat.util.net.jsse.openssl.TestOpenSSLCipherConfigurationParser.NIO.txt [concat] TEST-org.apache.tomcat.websocket.TestConnectionLimit.NIO.txt [concat] TEST-org.apache.tomcat.websocket.pojo.TestEncodingDecoding.NIO.txt [concat] Testsuites with failed tests: [concat] TEST-org.apache.tomcat.websocket.TestWebSocketFrameClientSSL.NIO.txt [concat] TEST-org.apache.tomcat.websocket.TestWsWebSocketContainer.NIO.txt This is on OS X 10.10.2 with Java 1.8.0_31 Logs attached. OK. The tests passed cleanly for me a couple of times on OSX 10.9.5 but failed on both the Linux and Windows VM. My impression is that there are a couple of timing issues still so sort out with the refactoring. I'll continue to look at them this week. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TestPojoEndpointBase failing on trunk
On 19/02/2015 18:27, Mark Thomas wrote: On 19/02/2015 15:17, Jeremy Boynes wrote: Mark I am seing regular failures in TestPojoEndpointBase in trunk where the socket is not being closed (see attached log). I’ve not dug in yet but this has started since r1660358 and may be related to recent NIO changes (maybe r1660582?). I'm fairly sure I have a fix for that wrapped up in my current changes. I'll get those committed as soon as I can but I am still working through intermittent unit test failures. To add to the 'fun' my email provider has decided the most helpful thing they could do is add a random 20 min to 12+ hour delay to all my e-mail. That is causing its own problems - not least of which is me not seeing dev@ e-mails in a timely manner. Unsurprisingly DynDNS will be losing a customer just as quickly as I can find an alternative to migrate to. Goodbye to the incompetence of DynDNS / DuoCircle. Hello to DNSExit/GhettoSMTP and a system that works (and costs 50% to 75% less). Having exchanged emails and instant messages with representatives of both companies I already have a much warmer feeling about them than I did with DynDNS and DuoCircle. Obviously time will tell in terms of service but so far so good. Now I have e-mail arriving with seconds of it being sent, back to what I'd much rather be doing... I think I have a fix for this that I have just committed. The unit tests pass consistently (so far) on OSX. Now I am back at home, I'll run them on Windows and Linux as well as BuildBot and Gump. There are still some strange failures on Gump that I don't understand at all. Any help investigating those would be much appreciated. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TestPojoEndpointBase failing on trunk
On Feb 22, 2015, at 10:57 AM, Mark Thomas ma...@apache.org wrote: On 19/02/2015 18:27, Mark Thomas wrote: On 19/02/2015 15:17, Jeremy Boynes wrote: Mark I am seing regular failures in TestPojoEndpointBase in trunk where the socket is not being closed (see attached log). I’ve not dug in yet but this has started since r1660358 and may be related to recent NIO changes (maybe r1660582?). I'm fairly sure I have a fix for that wrapped up in my current changes. I'll get those committed as soon as I can but I am still working through intermittent unit test failures. To add to the 'fun' my email provider has decided the most helpful thing they could do is add a random 20 min to 12+ hour delay to all my e-mail. That is causing its own problems - not least of which is me not seeing dev@ e-mails in a timely manner. Unsurprisingly DynDNS will be losing a customer just as quickly as I can find an alternative to migrate to. Goodbye to the incompetence of DynDNS / DuoCircle. Hello to DNSExit/GhettoSMTP and a system that works (and costs 50% to 75% less). Having exchanged emails and instant messages with representatives of both companies I already have a much warmer feeling about them than I did with DynDNS and DuoCircle. Obviously time will tell in terms of service but so far so good. Now I have e-mail arriving with seconds of it being sent, back to what I'd much rather be doing... I think I have a fix for this that I have just committed. The unit tests pass consistently (so far) on OSX. Now I am back at home, I'll run them on Windows and Linux as well as BuildBot and Gump. There are still some strange failures on Gump that I don't understand at all. Any help investigating those would be much appreciated. Thanks, this one is passing now. However, I’m seeing some other tests failing: test: [concat] Testsuites with skipped tests: [concat] TEST-org.apache.catalina.connector.TestRequest.NIO.txt [concat] TEST-org.apache.el.parser.TestELParser.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestCustomSsl.NIO.txt [concat] TEST-org.apache.tomcat.util.net.TestSsl.NIO.txt [concat] TEST-org.apache.tomcat.util.net.jsse.openssl.TestCipher.NIO.txt [concat] TEST-org.apache.tomcat.util.net.jsse.openssl.TestOpenSSLCipherConfigurationParser.NIO.txt [concat] TEST-org.apache.tomcat.websocket.TestConnectionLimit.NIO.txt [concat] TEST-org.apache.tomcat.websocket.pojo.TestEncodingDecoding.NIO.txt [concat] Testsuites with failed tests: [concat] TEST-org.apache.tomcat.websocket.TestWebSocketFrameClientSSL.NIO.txt [concat] TEST-org.apache.tomcat.websocket.TestWsWebSocketContainer.NIO.txt This is on OS X 10.10.2 with Java 1.8.0_31 Logs attached. Testsuite: org.apache.tomcat.websocket.TestWsWebSocketContainer Tests run: 26, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 70.925 sec - Standard Error - 22-Feb-2015 14:23:16.747 INFO [main] org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case [testMaxMessageSize01] 22-Feb-2015 14:23:17.007 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler [http-nio-127.0.0.1-auto-1] 22-Feb-2015 14:23:17.028 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Tomcat 22-Feb-2015 14:23:17.028 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/9.0.0-dev 22-Feb-2015 14:23:17.151 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-127.0.0.1-auto-1-51485] 22-Feb-2015 14:23:17.446 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler [http-nio-127.0.0.1-auto-1-51485] 22-Feb-2015 14:23:17.502 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service Tomcat 22-Feb-2015 14:23:17.509 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler [http-nio-127.0.0.1-auto-1-51485] 22-Feb-2015 14:23:17.511 INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler [http-nio-127.0.0.1-auto-1-51485] 22-Feb-2015 14:23:17.518 INFO [main] org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case [testMaxMessageSize02] 22-Feb-2015 14:23:17.519 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler [http-nio-127.0.0.1-auto-2] 22-Feb-2015 14:23:17.520 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Tomcat 22-Feb-2015 14:23:17.520 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/9.0.0-dev 22-Feb-2015 14:23:17.525 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-127.0.0.1-auto-2-51488] 22-Feb-2015 14:23:17.633 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler [http-nio-127.0.0.1-auto-2-51488]
TestPojoEndpointBase failing on trunk
Mark I am seing regular failures in TestPojoEndpointBase in trunk where the socket is not being closed (see attached log). I’ve not dug in yet but this has started since r1660358 and may be related to recent NIO changes (maybe r1660582?). Cheers Jeremy Testsuite: org.apache.tomcat.websocket.pojo.TestPojoEndpointBase Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.992 sec - Standard Error - 19-Feb-2015 07:12:20.251 INFO [main] org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case [testBug54716] 19-Feb-2015 07:12:20.680 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler [http-nio-127.0.0.1-auto-1] 19-Feb-2015 07:12:20.703 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Tomcat 19-Feb-2015 07:12:20.703 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/9.0.0-dev 19-Feb-2015 07:12:20.810 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-127.0.0.1-auto-1-49282] 19-Feb-2015 07:12:20.993 SEVERE [http-nio-127.0.0.1-auto-1-exec-1] org.apache.tomcat.websocket.pojo.PojoEndpointBase.onError No error handling configured for [org.apache.tomcat.websocket.pojo.TestPojoEndpointBase$Bug54716] and the following error occurred java.lang.RuntimeException at org.apache.tomcat.websocket.pojo.TestPojoEndpointBase$Bug54716.onOpen(TestPojoEndpointBase.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:66) at org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:70) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:691) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:181) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1698) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) 19-Feb-2015 07:12:25.997 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler [http-nio-127.0.0.1-auto-1-49282] 19-Feb-2015 07:12:26.055 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service Tomcat 19-Feb-2015 07:12:26.059 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [http-nio-127.0.0.1-auto-1-exec-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:93) org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:275) org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:570) org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:478) org.apache.tomcat.websocket.WsSession.close(WsSession.java:445) org.apache.tomcat.websocket.WsSession.close(WsSession.java:439) org.apache.tomcat.websocket.pojo.PojoEndpointBase.handleOnOpenOrCloseError(PojoEndpointBase.java:96) org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:79) org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:70) org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138) org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:691) org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:181) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741)
Re: TestPojoEndpointBase failing on trunk
On 19/02/2015 15:17, Jeremy Boynes wrote: Mark I am seing regular failures in TestPojoEndpointBase in trunk where the socket is not being closed (see attached log). I’ve not dug in yet but this has started since r1660358 and may be related to recent NIO changes (maybe r1660582?). I'm fairly sure I have a fix for that wrapped up in my current changes. I'll get those committed as soon as I can but I am still working through intermittent unit test failures. To add to the 'fun' my email provider has decided the most helpful thing they could do is add a random 20 min to 12+ hour delay to all my e-mail. That is causing its own problems - not least of which is me not seeing dev@ e-mails in a timely manner. Unsurprisingly DynDNS will be losing a customer just as quickly as I can find an alternative to migrate to. I think I am making progress with the unit test failures and I'll commit them just as soon as I am happy the code is in a better state than it is now. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
