Am 13.04.2017 um 15:12 schrieb Mark Thomas:
The proposed Apache Tomcat 8.5.14 release is now available for voting.

The major changes compared to the 8.5.13 release are:

- Correct a regression that broke JMX operations (including the Manager
  web application) if the operation took parameters

- Add JMX support for Tribes components

- Calls to isReady() no longer throw exceptions after timeouts for async
  servlets


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.14/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1132/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_14/

The proposed 8.5.14 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 8.5.14

+1 to release.

See end of mail for a comment on attribute keystorePass of MBean Catalina:type=ProtocolHandler,port=8080.

Details
=======

- SHA1 and MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src consistent with svn tag
  - except bin shell scripts are not executable in src tarball
    (not critical)
- builds fine
  - warning about unchecked calls or conversions in:
    - org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
    - org/apache/tomcat/jdbc/pool/PoolProperties.java
  Not a regression
- build result looks consistent with binaries
- no checkstyle complaints
- no Javadoc warnings

- Unit tests: No failures, below comparisons are against 8.5.13.

  - variable data in messages now often contained in "[]" (expected)

  - Exception:

    - no longer happen (happened once for 8.5.13):

java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [MUST_COMPLETE]

java.util.concurrent.RejectedExecutionException: Executor not running, can't force a command into the queue

Exception in thread "http-apr-127.0.0.1-auto-I-exec-PPPPP" java.lang.NullPointerException

- one less for NIO (1->0), one more for APR (0->1) org.apache.catalina.connector.CoyoteAdapter.asyncDispatch Exception while processing an asynchronous request

- new for NIO (0->1) org.apache.catalina.core.StandardHostValve.invoke Exception Processing /simple

- one less (4->3) java.io.IOException: The socket [NUMBER] associated with this connection has been closed.

- two more (3->5) org.apache.catalina.tribes.ChannelException: java.net.ConnectException: Connection refused; Faulty members:tcp://{IP}:PORT;
and
Caused by: java.net.ConnectException: Connection refused

    - one less (6->5) java.nio.channels.ClosedChannelException

    - two more (7->9) java.lang.NullPointerException

- one less (12->11) java.io.IOException: java.io.IOException: Broken pipe
and
Caused by: java.io.IOException: Broken pipe

- two more (7->9) org.apache.catalina.tribes.ChannelException: Sender not connected.; No faulty members identified.

- 5 more (1->6) [Tribes-Task-Receiver-T] org.apache.catalina.tribes.transport.nio.NioReplicationTask.run IOException in replication worker, unable to drain channel. Probable cause: Keep alive socket closed[null].


  - SEVERE messages

- no more for APR (2->0) org.apache.tomcat.util.net.AprEndpoint$Poller.run Poller failed with error [NUMBER] : [Bad file number]

- one new for NIO org.apache.catalina.core.StandardHostValve.invoke Exception Processing /simple

- one less for APR and NIO (1->0) org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [simple] in context with path [] threw exception

- two new for APR (0->2) org.apache.coyote.http11.Http11Processor.endRequest Error finishing response

- one less for NIO (3->2) org.apache.coyote.http11.Http11Processor.service Error processing request

- one less for APR (5->4) org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading request, ignored

- 4 more (7-11) [Tribes-Task-Receiver-T] org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.messageReceived Error processing coordination message. Could be fatal.


  - WARN messages

- no more (1->0) org.apache.tomcat.util.net.AbstractEndpoint.processSocket Executor rejected socket [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@HEX:org.apache.tomcat.util.net.Nio2Channel@HEX:sun.nio.ch.UnixAsynchronousSocketChannelImpl[closed]] for processing

- one new (0->1) org.apache.catalina.tribes.transport.nio.ParallelNioSender.doLoop Member send is failing for:tcp://{IP}:PORT ; Setting to suspect and retrying.

- one more (2->3) [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] is still processing a request that has yet to finish. This is very likely to create a memory leak. You can control the time allowed for requests to finish by using the unloadDelay attribute of the standard Context implementation. Stack trace of request processing thread:

- two less (10->8) [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [pool-P-thread-T] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:

- two more (7->9) [Tribes-Task-Receiver-T] org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.sendElectionMsgToNextInline Unable to send election message to:org.apache.catalina.tribes.membership.MemberImpl[tcp://IP:PORT,IP,PORT, alive=AAA, securePort=-1, UDP Port=-1, id={...}, payload={}, command={...}, domain={...}, ]

- two more (7->9) [Tribes-Task-Receiver-T] org.apache.catalina.tribes.transport.nio.ParallelNioSender.doLoop Member send is failing for:tcp://{IP}:PORT ; Setting to suspect and retrying.

- three more (45->48) [Tribes-Task-Receiver-T] org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.sendElectionMsgToNextInline Unable to send election message to:org.apache.catalina.tribes.membership.MemberImpl[tcp://{IP}:PORT,{IP},PORT, alive=AAA, securePort=-1, UDP Port=-1, id={...}, payload={}, command={}, domain={...}, ]


- JMX MBean Comparison with 8.5.13:

  - MBean Catalina:type=ProtocolHandler,port=8080 new attribute
    "keystorePass: changeit". Not sure whether exposure of password
    is expected here. In TC 9 it seems it was first exposed in M19.

Build and tests were done using Java 1.7.0_80. OS was Solaris 10 Sparc, tcnative was 1.2.12 based on APR 1.5.2 and OpenSSL 1.0.2k plus patches.

Thanks for RM and regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to