On 18.10.2013 13:14, Violeta Georgieva wrote:
> The proposed Apache Tomcat 7.0.47 release is now available for voting.
> This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
> Note that use of this functionality requires Java 7.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.47/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-192/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_47/
>
> The proposed 7.0.47 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.47 Stable
+1 to release.
Details:
- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src completely consistent with svn tag, except
file
res/META-INF/tomcat7-websocket.jar/services/javax.servlet.ServletContainerInitializer
which has
Unix line ends in svn, but DOS in tar.gz src download
(Not a show-stopper)
- builds fine
- warning about unsafe or unchecked operations in:
- o.a.t.dbcp (many)
- javax/el/ResourceBundleELResolver.java:109 (old)
Much less than for 7.0.42
- build result looks consistent with binaries
- no checkstyle complaints
- some Javadoc warnings
- in jdbc-pool: DataSourceProxy.java:544: Tag @link: can't
find getParentLogger in javax.sql.DataSource (not a new one)
- in AprEndpoint @returns is an unknown tag (fixed in r1533732)
- in o.a.t.websocket: lots of errors, probably due to the need of
Java 7 for this part, but javadoc running under Java 6. Maybe
we can use java.7.home to run javadoc if set. (new)
- Unit tests:
- error in org.apache.catalina.websocket.TestWebSocket for BIO
- failure in
org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak for APR
- Details see below
- JMX MBean-Comparison only expected delta:
- some servlet class names moved from websocket to websocket.tc7
- ProtocolHandler MBean new attribute "connectionCount"
(previously only available in ThreadPool)
- ProtocolHandler MBean for http new attribute maxExtensionSize
- OperatingSystem MBean OpenFileDescriptorCount down from 61 to 57,
System Property ...TldConfig.jarsToSkip now contains
tomcat7-websocket.jar, ...DefaultJarScanner.jarsToSkip now added
entries websocket-api.jar, hamcrest*.jar and org.hamcrest*.jar
Build and tests were done using Java 1.6.0_45, java.7.home was pointing
to 1.7.0_45. OS was Solaris 10 Sparc, tcnative was 1.1.29 based on APR
1.4.8 and OpenSSL 1.0.1e (plus a few patches).
- Unit error in org.apache.catalina.websocket.TestWebSocket for BIO
Testcase: testBug53339 took 15.281 sec
Caused an ERROR
Read timed out
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at
org.apache.catalina.websocket.TestWebSocket$WebSocketClient.readMessage(TestWebSocket.java:456)
at
org.apache.catalina.websocket.TestWebSocket$WebSocketClient.access$300(TestWebSocket.java:383)
at
org.apache.catalina.websocket.TestWebSocket.testBug53339(TestWebSocket.java:327)
Maybe related to:
Oct 18, 2013 10:07:06 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-bio-127.0.0.1-auto-2-51242"]
Oct 18, 2013 10:07:11 PM org.apache.tomcat.util.net.AbstractEndpoint
shutdownExecutor
WARNING: The executor associated with thread pool
[http-bio-127.0.0.1-auto-2] has not fully shutdown. Some application
threads may still be running.
Oct 18, 2013 10:07:11 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-bio-127.0.0.1-auto-2-51242"]
Oct 18, 2013 10:07:11 PM org.apache.coyote.AbstractProtocol init
- Unit test failure in
org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak for APR
Testcase: testTimerThreadLeak took 4.611 sec
FAILED
Timer thread still running
junit.framework.AssertionFailedError: Timer thread still running
at
org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.testTimerThreadLeak(TestWebappClassLoaderMemoryLeak.java:72)
Unit test warnings (very similar to 7.0.42, but the two ones that were
new in 42 are gone again in 47, one new one in 47, numbers also higher
for tribes):
- org.apache.catalina.deploy.TestWebXmlOrdering
- BIO, NIO and APR: [main]
org.apache.catalina.deploy.WebXml.orderWebFragments Used a wrong
fragment name z at web.xml absolute-ordering tag!
- org.apache.tomcat.util.net.TestCustomSsl
- BIO twice "Exception getting SSL attributes"
in org.apache.coyote.http11.Http11Processor actionInternal
exception is:
javax.net.ssl.SSLProtocolException: handshake alert: no_certificate
- NIO twice "WARNING: Exception re-negotiating SSL connection"
in org.apache.coyote.http11.Http11NioProcessor actionInternal
- WARNING: The executor associated with thread pool [...] has not fully
shutdown. Some application threads may still be running. (new)
- Only for BIO, once in org.apache.catalina.connector.TestInputBuffer,
once in org.apache.catalina.websocket.TestWebSocket
- tribes: several warnings (47), numbers much higher (+28) than 7.0.42.
Same types of messages. Most new ones are of type:
org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.sendElectionMsgToNextInline
Unable to send election message to: ...
Unit test SEVERE messages: 242 total (+21).
Most of those are of type "Servlet.service() for servlet ... threw
exception" (140 times, +3).
Second biggest block (unchanged):
Count message
27 [junit] TIMESTAMP SEVERE [main]
org.apache.tomcat.util.digester.Digester.startElement Begin event threw
exception
3 [junit] TIMESTAMP SEVERE [main]
org.apache.tomcat.util.digester.Digester.endElement End event threw
exception
Third biggest block is 33 (+14) messages from the mem leak detection
during context unload:
- 18 times (+8): The web application [...] appears to have started a
thread named [...] but has failed to stop it. This is very likely to
create a memory leak.
- 6 times (all new): The web application [] 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.
- it happens twice in org.apache.catalina.connector.TestMaxConnections
for BIO, NIO and APR
"Exception" in output of unit tests: 231 times (+12).
Top exception counts (unchanged):
75 [junit] javax.servlet.ServletException: Opps.
9 [junit] java.io.IOException: Invalid CRLF, no CR character
encountered.
9 [junit] java.lang.IllegalArgumentException: <ordering> element
is limited to 1 occurrence
9 [junit] java.lang.IllegalArgumentException: <name> element is
limited to 1 occurrence
9 [junit] java.lang.IllegalArgumentException:
<absolute-ordering> element is limited to 1 occurrence
6 [junit] org.apache.jasper.JasperException:
/bug49nnn/bug49297DuplicateAttr.jsp (line: 21, column: 46) Attribute
qualified names must be unique within an element
6 (new) [junit] Exception in thread "WebSocketClient-AsyncIO-NNN"
java.lang.IllegalStateException: Writing not allowed due to timeout or
cancellation (twice each for BIO, NIO and APR in
org.apache.tomcat.websocket.TestWsWebSocketContainer)
The other new ones are:
5 org.apache.catalina.tribes.ChannelException: Sender not connected.; No
faulty members identified.
resulting in
org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.messageReceived
Error processing coordination message. Could be fatal.
3 java.lang.RuntimeException
All in org.apache.tomcat.websocket.pojo.TestPojoEndpointBase, once
for BIO, NIO and APR, leading to:
SEVERE: No error handling configured for
[org.apache.tomcat.websocket.pojo.TestPojoEndpointBase$Bug54716] and the
following error occurred
3 java.io.IOException: maxExtensionSize exceeded
All in org.apache.coyote.http11.filters.TestChunkedInputFilter, once
for BIO, NIO and APR, leading to:
SEVERE: Servlet.service() for servlet [servlet] in context with path []
threw exception
1 java.io.IOException: Unexpected error [70,014] reading data from the
APR/native socket [10,110,520].
(once in org.apache.catalina.websocket.TestWebSocket for APR leading to
SEVERE: No error handling configured for
[org.apache.tomcat.websocket.TesterEchoServer$Basic] and the following
error occurred)
I'm not claiming that any of the SEVERE or Exception messages are
important. Total numbers of warnings, SEVERE and exceptions are
about the same than for previous releases.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
