You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2015/10/31 20:17:21 UTC
Plan for Tomcat native 1.2.1
Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
than later and then use that with 9.0.0.RC1.
I think all the issues discovered so far have been fixed. If you know of
one that hasn't, please speak up.
Also, don't forget to update the changelog for the fixes you have made.
I'm currently planning on tagging 1.2.1 this coming Monday (2015-11-02).
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for Tomcat native 1.2.1
Posted by Rainer Jung <ra...@kippdata.de>.
Am 31.10.2015 um 20:17 schrieb Mark Thomas:
> Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
> than later and then use that with 9.0.0.RC1.
>
> I think all the issues discovered so far have been fixed. If you know of
> one that hasn't, please speak up.
I noted a crash in TestWebSocketFrameClientSSL, but Bill Barker said
"This has been crashing in Gump for a long time", so I guess you are
aware of that problem.
For details see below.
> Also, don't forget to update the changelog for the fixes you have made.
ACK but most of my changes IMHO do not warrant a changelog entry. Will
have another look.
> I'm currently planning on tagging 1.2.1 this coming Monday (2015-11-02).
+1
Details for the unit test crash:
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libssl.so.1.0.0+0x302cc] ssl3_write_bytes+0x52c
C [libssl.so.1.0.0+0x2da84] ssl3_write+0x64
C [libssl.so.1.0.0+0x48a40] SSL_write+0x40
C [libtcnative-1.so.0.2.0+0x1ea94] ssl_socket_send+0x6c
C [libtcnative-1.so.0.2.0+0x15bac]
Java_org_apache_tomcat_jni_Socket_sendb+0x70
j org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I+78334172
j org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I+0
j
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doWriteInternal()V+89
j
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doWriteInternal(Z)V+85
j org.apache.tomcat.util.net.SocketWrapperBase.doWrite(Z)V+2
j org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking()V+2
j org.apache.tomcat.util.net.SocketWrapperBase.flush(Z)Z+16
j
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(Ljavax/websocket/SendHandler;J[Ljava/nio/ByteBuffer;)V+188
j
org.apache.tomcat.websocket.WsRemoteEndpointImplBase$OutputBufferSendHandler.write()V+263
j
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(Lorg/apache/tomcat/websocket/MessagePart;)V+353
j
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(BLjava/nio/ByteBuffer;ZJ)V+177
j
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(Ljava/nio/CharBuffer;Z)V+101
j
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(Ljava/lang/String;)V+33
j
org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(Ljava/lang/String;)V+5
j
org.apache.tomcat.websocket.TesterFirehoseServer$Endpoint.onMessage(Ljavax/websocket/Session;Ljava/lang/String;)V+117
...
j
org.apache.tomcat.websocket.pojo.PojoMessageHandlerWholeBase.onMessage(Ljava/lang/Object;)V+147
j org.apache.tomcat.websocket.WsFrameBase.sendMessageText(Z)V+142
j org.apache.tomcat.websocket.WsFrameBase.processDataText()Z+425
j org.apache.tomcat.websocket.WsFrameBase.processData()Z+41
j org.apache.tomcat.websocket.WsFrameBase.processInputBuffer()V+81
j org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable()V+69
j
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(Lorg/apache/tomcat/util/net/SocketStatus;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;+64
j
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(Lorg/apache/tomcat/util/net/SocketStatus;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;+5
j
org.apache.coyote.AbstractProcessorLight.process(Lorg/apache/tomcat/util/net/SocketWrapperBase;Lorg/apache/tomcat/util/net/SocketStatus;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;+81
j
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Lorg/apache/tomcat/util/net/SocketWrapperBase;Lorg/apache/tomcat/util/net/SocketStatus;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState;+259
j org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run()V+35
j
java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5
j org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()V+4
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0x750588] void
JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0xa58
V [libjvm.so+0x74e9b4] void
JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x370
V [libjvm.so+0x74ec78] void
JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x50
V [libjvm.so+0x881a7c] void thread_entry(JavaThread*,Thread*)+0xdc
V [libjvm.so+0xd64ae4] void JavaThread::thread_main_inner()+0x94
V [libjvm.so+0xd64a30] void JavaThread::run()+0x398
V [libjvm.so+0xb9f980] java_start+0x390
C [libc.so.1+0xd64c0] _lwp_start+0x8
Before the crash, the test logged:
[junit] Running org.apache.tomcat.websocket.TestWebSocketFrameClientSSL
[junit] 30-Oct-2015 23:27:10.759 INFO [main]
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
[testBug56032]
[junit] 30-Oct-2015 23:27:11.499 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library 1.2.0 using APR version 1.5.2.
[junit] 30-Oct-2015 23:27:11.500 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true].
[junit] 30-Oct-2015 23:27:11.526 INFO [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized (OpenSSL 1.0.2d 9 Jul 2015)
[junit] 30-Oct-2015 23:27:12.709 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-apr-127.0.0.1-auto-1"]
[junit] 30-Oct-2015 23:27:12.781 INFO [main]
org.apache.catalina.core.StandardService.startInternal Starting service
Tomcat
[junit] 30-Oct-2015 23:27:12.782 INFO [main]
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
Engine: Apache Tomcat/9.0.0-dev
[junit] 30-Oct-2015 23:27:13.586 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
[https-apr-127.0.0.1-auto-1-37331]
[junit] Waiting for server to report an error
[junit] Received Hello, now sending data
[junit] 30-Oct-2015 23:32:16.526 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["https-apr-127.0.0.1-auto-1-37331"]
[junit] 30-Oct-2015 23:32:16.600 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
Tomcat
[junit] 30-Oct-2015 23:32:21.621 WARNING [localhost-startStop-2]
org.apache.tomcat.websocket.WsSession.doClose Failed to flush batched
messages on session close
[junit] java.net.SocketTimeoutException
[junit] at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:295)
[junit] at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:256)
[junit] at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.flushBatch(WsRemoteEndpointImplBase.java:119)
[junit] at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.setBatchingAllowed(WsRemoteEndpointImplBase.java:106)
[junit] at
org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:469)
[junit] at
org.apache.tomcat.websocket.WsSession.close(WsSession.java:444)
[junit] at
org.apache.tomcat.websocket.WsWebSocketContainer.destroy(WsWebSocketContainer.java:789)
[junit] at
org.apache.tomcat.websocket.server.WsServerContainer.destroy(WsServerContainer.java:280)
[junit] at
org.apache.tomcat.websocket.server.WsContextListener.contextDestroyed(WsContextListener.java:48)
[junit] at
org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4780)
[junit] at
org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5401)
[junit] at
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:237)
[junit] at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1420)
[junit] at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1409)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit]
Where apr crashed, nio logged the same SocketTimeoutException and then
[junit] 31-Oct-2015 00:22:04.519 INFO
[https-nio-127.0.0.1-auto-1-exec-5]
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doClose
Failed to close the ServletOutputStream connection cleanly
[junit] java.io.IOException: Remaining data in the network buffer,
can't send SSL close message, force a close with close(true) instead
[junit] at
org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioChannel.java:478)
[junit] at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.close(NioEndpoint.java:1244)
[junit] at
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doClose(WsRemoteEndpointImplServer.java:172)
[junit] at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.close(WsRemoteEndpointImplBase.java:698)
[junit] at
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:577)
[junit] at
org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:508)
[junit] at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.close(WsHttpUpgradeHandler.java:234)
[junit] at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:150)
[junit] at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
[junit] at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:56)
[junit] at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:737)
[junit] at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1531)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit]
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for Tomcat native 1.2.1
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-10-31 22:17 GMT+03:00 Mark Thomas <ma...@apache.org>:
> Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
> than later and then use that with 9.0.0.RC1.
>
> I think all the issues discovered so far have been fixed. If you know of
> one that hasn't, please speak up.
I think that Bill's commit to s/SSL/TLS/ in a constant name has to be
applied to trunk as well.
http://svn.apache.org/viewvc?view=revision&revision=1711567
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for Tomcat native 1.2.1
Posted by Rainer Jung <ra...@kippdata.de>.
Am 31.10.2015 um 20:17 schrieb Mark Thomas:
> Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
> than later and then use that with 9.0.0.RC1.
>
> I think all the issues discovered so far have been fixed. If you know of
> one that hasn't, please speak up.
One other observation: there's a compiler warning about potential use of
two uninitialized variables in native/src/sslutils.c. It seems it will
be triggered if in select_next_proto() the parameter
supported_protos_len is 0 or inlen is 0. I added a marker in r1711584,
but I don't currently know how to fix that (or whether we can exclude
the occurrence of 0 as a parameter value).
> Also, don't forget to update the changelog for the fixes you have made.
>
> I'm currently planning on tagging 1.2.1 this coming Monday (2015-11-02).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for Tomcat native 1.2.1
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 10/31/15 3:54 PM, Rémy Maucherat wrote:
> 2015-10-31 20:17 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
>> than later and then use that with 9.0.0.RC1.
>>
>> I think all the issues discovered so far have been fixed. If you know of
>> one that hasn't, please speak up.
>>
>> Also, don't forget to update the changelog for the fixes you have made.
>>
>> I'm currently planning on tagging 1.2.1 this coming Monday (2015-11-02).
>>
>> +1
>
> Thanks for fixing it so quickly.
+1
I'll build on a few Linux systems to help out. I'm sorry I didn't have a
chance to test this release before the vote conclusion.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Plan for Tomcat native 1.2.1
Posted by Rémy Maucherat <re...@apache.org>.
2015-10-31 20:17 GMT+01:00 Mark Thomas <ma...@apache.org>:
> Given the issues with 1.2.0, I'd like to get 1.2.1 out sooner rather
> than later and then use that with 9.0.0.RC1.
>
> I think all the issues discovered so far have been fixed. If you know of
> one that hasn't, please speak up.
>
> Also, don't forget to update the changelog for the fixes you have made.
>
> I'm currently planning on tagging 1.2.1 this coming Monday (2015-11-02).
>
> +1
Thanks for fixing it so quickly.
Rémy