[Bug 55675] Checking and handling invalid configuration option values
https://issues.apache.org/bugzilla/show_bug.cgi?id=55675 Mark Thomas ma...@apache.org changed: What|Removed |Added OS||All Severity|normal |enhancement --- Comment #1 from Mark Thomas ma...@apache.org --- Improving handling of invalid configuration is an enhancement rather than a bug. The configuration style used in McastService is not one widely used in Tomcat although I suspect it may be used elsewhere in the org.apache.catalina.tribes package. I'd be happy to see the properties field removed and replaced with standard getters and setters with appropriate defaults. If necessary (I'm not sure it is) , those defaults can be invalid and the implementation can check that they have been set to valid values at an appropriate point. As always, patches welcome. Note that changes like this that modify the API are less likely to be back-ported to earlier versions of Tomcat. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55674] ThreadLocal memory leak clean-up causes huge log
https://issues.apache.org/bugzilla/show_bug.cgi?id=55674 --- Comment #1 from Mark Thomas ma...@apache.org --- The attribute names and values are logged to assist with the identification of the cause of the memory leak. Memory leaks are logged at SEVERE as they represent a serious bug that could eventually lead to an OOME. Tomcat's leak detection and prevention code should reduce the chances of an OOME but it may not eliminate it. Since neither the severity level nor the use of toString() is going to change, I am resolving this as WONTFIX. That said, there is a long standing enhancement request (bug 50715) to modify the leak detection code so the warnings are skipped / logged at a lower level when the leaks don't matter (e.g. when the JVM is shutting down). Some recent work on a unrelated issue means I have some useful info to add to that bug so I'll do that shortly. I'll add 50715 to my TODO list as the features it requires are likely to be useful elsewhere. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55674] ThreadLocal memory leak clean-up causes huge log
https://issues.apache.org/bugzilla/show_bug.cgi?id=55674 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55674] ThreadLocal memory leak clean-up causes huge log
https://issues.apache.org/bugzilla/show_bug.cgi?id=55674 --- Comment #2 from Mark Thomas ma...@apache.org --- Whoops, I mean bug 50175. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 50175] Enhance memory leak detection by selectively applying methods,
https://issues.apache.org/bugzilla/show_bug.cgi?id=50175 --- Comment #6 from Mark Thomas ma...@apache.org --- First of all, the memory leak detection is not going to be disabled. For far too long Tomcat was being blamed for PermGen based OOME errors triggered by web application reloads. The leak detection code has proved invaluable in raising awareness of what the real root causes are and in getting a number of the leaks in popular 3rd party libraries fixed. I'd disagree with the view that leaks don't matter in production as it depends on how applications are managed. I do agree it is an issue that can safely be ignored some use cases. What would be very useful - both for this issue and for others - would be a way to determine when any Tomcat component is stopped is whether it is being stopped because: - the JVM is shutting down - Tomcat is shutting down (e.g. in an embedded scenario) - just the component is being stopped (e.g. a web app is being undeployed or reloaded) I've been giving this some thought recently and I have some ideas about how this might be done. I need to turn those ideas into code and see how well they work. If I come up with a viable solution I add it to Tomcat 8. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC5
On 16/10/2013 19:21, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 5 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC4 are: - Stability fixes in the APR/native connector - Stability fixes for non-blocking IO and WebSocket - Improvements to unit tests to reduce incidence of false reports - Add a drawing board example to the WebSocket examples - A handful of bug fixes - A small number of enhancements including direct gzip support in the default Servlet - More HTML clean-up It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC5/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-186/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC5/ The proposed 8.0.0-RC5 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC5 alpha Unit tests pass consistently on Windows, Linux and OSX. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.47
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. ... The proposed 7.0.47 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 7.0.47 Stable Tested .zip distribution on Windows 7 64-bit: - Tested SSL/TLS connectivity for BIO, NIO and APR connectors. - Crawled all links (except /manager, /host-manager and /examples/async*). No broken links found, except links to JavaDocs. - Smoke tests of BIO, NIO and APR, with and without TLS, all passed. -Ognjen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1533732 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java
Author: rjung
Date: Sat Oct 19 11:32:00 2013
New Revision: 1533732
URL: http://svn.apache.org/r1533732
Log:
Javadoc fixes.
Partial backport of r1531099 from trunk.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1531099
Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1533732r1=1533731r2=1533732view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Sat
Oct 19 11:32:00 2013
@@ -1143,8 +1143,8 @@ public class AprEndpoint extends Abstrac
/**
* Removes the specified socket from the poller.
*
- * @returns The configured timeout for the socket or zero if the socket
- * was not in the list of socket timeouts
+ * @return The configured timeout for the socket or zero if the socket
+ * was not in the list of socket timeouts
*/
public long remove(long socket) {
long result = 0;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer bob.dere...@thingworx.comwrote: Hi Guys, ** ** In our implementation, we have a gateway app that uses jsr websockets to communication with our main application server. In a small system, we want to run them both on a single Tomcat instance using the same Tomcat NIO connector, but directing to different respective WS paths. This works fine if you deploy the MAIN first, then the GW – so that MAIN is already up and running. If you restart Tomcat when both webapps are deployed – and the GW (client) starts first, it hangs indefinitely in the following code trying to establish a WS connection: Hi Bob, Do you use the latest implementation? In your case, if got it correctly, we have following: a socket listening and missing context ** ** Is this a bug or a known limitation when a client/server in the same webapp try to connect at startup? ** ** Thanks ** ** localhost-startStop-1 daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting on condition [0x1046e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x0007d6d98b18 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:568) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:317) at com.thingworx.core.communication.channels.jsr356.client.Jsr356ClientChannel.connect(Jsr356ClientChannel.java:57) at com.thingworx.core.communication.endpoints.CommunicationEndpoint.connect(CommunicationEndpoint.java:186) at com.thingworx.core.communication.CommunicationSubsystem.startSubsystem(CommunicationSubsystem.java:88) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)** ** at com.thingworx.apiserver.APIServerManager.startSubsystem(APIServerManager.java:92) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)** ** at com.thingworx.apiserver.Bootstrapper.contextInitialized(Bootstrapper.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) ** ** Locked ownable synchronizers: - 0x0007da3a7ab0 (a java.util.concurrent.ThreadPoolExecutor$Worker) ** ** ** ** ** ** *Bob DeRemer* *Senior Director, Architecture and Development* ** ** [image: Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.com Skype: bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986 ** **
Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
On Sat, Oct 19, 2013 at 4:20 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer bob.dere...@thingworx.comwrote: Hi Guys, ** ** In our implementation, we have a gateway app that uses jsr websockets to communication with our main application server. In a small system, we want to run them both on a single Tomcat instance using the same Tomcat NIO connector, but directing to different respective WS paths. This works fine if you deploy the MAIN first, then the GW – so that MAIN is already up and running. If you restart Tomcat when both webapps are deployed – and the GW (client) starts first, it hangs indefinitely in the following code trying to establish a WS connection: Hi Bob, Do you use the latest implementation? In your case, if got it correctly, we have following: 1. a socket listening - Hence connections are processed 2. missing application - Hence 404 Not Found status code is expected I expect to have 404 response code on initial upgrade request cheers Niki (sorry for previous partial response, hit send by mistake) ** ** Is this a bug or a known limitation when a client/server in the same webapp try to connect at startup? ** ** Thanks ** ** localhost-startStop-1 daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting on condition [0x1046e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x0007d6d98b18 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:568) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:317) at com.thingworx.core.communication.channels.jsr356.client.Jsr356ClientChannel.connect(Jsr356ClientChannel.java:57) at com.thingworx.core.communication.endpoints.CommunicationEndpoint.connect(CommunicationEndpoint.java:186) at com.thingworx.core.communication.CommunicationSubsystem.startSubsystem(CommunicationSubsystem.java:88) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)* *** at com.thingworx.apiserver.APIServerManager.startSubsystem(APIServerManager.java:92) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java:48)* *** at com.thingworx.apiserver.Bootstrapper.contextInitialized(Bootstrapper.java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) ** ** Locked ownable synchronizers: - 0x0007da3a7ab0 (a java.util.concurrent.ThreadPoolExecutor$Worker) ** ** ** ** ** ** *Bob DeRemer* *Senior Director, Architecture and Development* ** ** [image: Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.com Skype: bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986 ** **
RE: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
-Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Saturday, October 19, 2013 9:24 AM To: Tomcat Developers List Subject: Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely On Sat, Oct 19, 2013 at 4:20 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer bob.dere...@thingworx.comwrote: Hi Guys, ** ** In our implementation, we have a gateway app that uses jsr websockets to communication with our main application server. In a small system, we want to run them both on a single Tomcat instance using the same Tomcat NIO connector, but directing to different respective WS paths. This works fine if you deploy the MAIN first, then the GW - so that MAIN is already up and running. If you restart Tomcat when both webapps are deployed - and the GW (client) starts first, it hangs indefinitely in the following code trying to establish a WS connection: Hi Bob, Do you use the latest implementation? In your case, if got it correctly, we have following: This was with the latest TAGGED code (7.0.47), not trunk. If this was a known issue that's fixed in TRUNK, let me know and I'll test it out. Thx - bob 1. a socket listening - Hence connections are processed 2. missing application - Hence 404 Not Found status code is expected I expect to have 404 response code on initial upgrade request cheers Niki (sorry for previous partial response, hit send by mistake) ** ** Is this a bug or a known limitation when a client/server in the same webapp try to connect at startup? ** ** Thanks ** ** localhost-startStop-1 daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting on condition [0x1046e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x0007d6d98b18 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared Interruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedIn terruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)*** * at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWe bSocketContainer.java:568) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWe bSocketContainer.java:317) at com.thingworx.core.communication.channels.jsr356.client.Jsr356ClientC hannel.connect(Jsr356ClientChannel.java:57) at com.thingworx.core.communication.endpoints.CommunicationEndpoint.conn ect(CommunicationEndpoint.java:186) at com.thingworx.core.communication.CommunicationSubsystem.startSubsyste m(CommunicationSubsystem.java:88) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java: 48)* *** at com.thingworx.apiserver.APIServerManager.startSubsystem(APIServerMana ger.java:92) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java: 48)* *** at com.thingworx.apiserver.Bootstrapper.contextInitialized(Bootstrapper. java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:4939) at org.apache.catalina.core.StandardContext.startInternal(StandardContex t.java:5434) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)* *** - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase. java:1559) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase. java:1549) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at java.lang.Thread.run(Thread.java:744) ** ** Locked ownable synchronizers: - 0x0007da3a7ab0 (a
Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
On Sat, Oct 19, 2013 at 4:26 PM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Saturday, October 19, 2013 9:24 AM To: Tomcat Developers List Subject: Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely On Sat, Oct 19, 2013 at 4:20 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer bob.dere...@thingworx.comwrote: Hi Guys, ** ** In our implementation, we have a gateway app that uses jsr websockets to communication with our main application server. In a small system, we want to run them both on a single Tomcat instance using the same Tomcat NIO connector, but directing to different respective WS paths. This works fine if you deploy the MAIN first, then the GW - so that MAIN is already up and running. If you restart Tomcat when both webapps are deployed - and the GW (client) starts first, it hangs indefinitely in the following code trying to establish a WS connection: Hi Bob, Do you use the latest implementation? In your case, if got it correctly, we have following: This was with the latest TAGGED code (7.0.47), not trunk. If this was a known issue that's fixed in TRUNK, let me know and I'll test it out. Thx - bob I tested with a sample app that has an annotated server endpoint,an annotated client endpoint and a context listener. In the listener, I obtain instance of ServerContainer and try to connect to the server endpoint. In both implementations (trunk and tc7.0.x) I got javax.websocket.DeploymentException: The HTTP response from the server [HTTP/1.1 404 Not Found] did not permit the HTTP upgrade to WebSocket as expected. However, the response processing is a blocking operation and can lead to the wait you describe. Can you isolate the case with a test app? Obviously I'm missing something. 1. a socket listening - Hence connections are processed 2. missing application - Hence 404 Not Found status code is expected I expect to have 404 response code on initial upgrade request cheers Niki (sorry for previous partial response, hit send by mistake) ** ** Is this a bug or a known limitation when a client/server in the same webapp try to connect at startup? ** ** Thanks ** ** localhost-startStop-1 daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting on condition [0x1046e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x0007d6d98b18 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared Interruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedIn terruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)*** * at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWe bSocketContainer.java:568) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWe bSocketContainer.java:317) at com.thingworx.core.communication.channels.jsr356.client.Jsr356ClientC hannel.connect(Jsr356ClientChannel.java:57) at com.thingworx.core.communication.endpoints.CommunicationEndpoint.conn ect(CommunicationEndpoint.java:186) at com.thingworx.core.communication.CommunicationSubsystem.startSubsyste m(CommunicationSubsystem.java:88) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java: 48)* *** at com.thingworx.apiserver.APIServerManager.startSubsystem(APIServerMana ger.java:92) at com.thingworx.core.subsystems.SubsystemBase.start(SubsystemBase.java: 48)* *** at com.thingworx.apiserver.Bootstrapper.contextInitialized(Bootstrapper. java:57) at org.apache.catalina.core.StandardContext.listenerStart(StandardContex t.java:4939) at org.apache.catalina.core.StandardContext.startInternal(StandardContex t.java:5434) - locked 0x0007da3e0308 (a org.apache.catalina.core.StandardContext) at
RE: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
-Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Saturday, October 19, 2013 10:06 AM To: Tomcat Developers List Subject: Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely On Sat, Oct 19, 2013 at 4:26 PM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Saturday, October 19, 2013 9:24 AM To: Tomcat Developers List Subject: Re: websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely On Sat, Oct 19, 2013 at 4:20 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer bob.dere...@thingworx.comwrote: Hi Guys, ** ** In our implementation, we have a gateway app that uses jsr websockets to communication with our main application server. In a small system, we want to run them both on a single Tomcat instance using the same Tomcat NIO connector, but directing to different respective WS paths. This works fine if you deploy the MAIN first, then the GW - so that MAIN is already up and running. If you restart Tomcat when both webapps are deployed - and the GW (client) starts first, it hangs indefinitely in the following code trying to establish a WS connection: Hi Bob, Do you use the latest implementation? In your case, if got it correctly, we have following: This was with the latest TAGGED code (7.0.47), not trunk. If this was a known issue that's fixed in TRUNK, let me know and I'll test it out. Thx - bob I tested with a sample app that has an annotated server endpoint,an annotated client endpoint and a context listener. In the listener, I obtain instance of ServerContainer and try to connect to the server endpoint. In both implementations (trunk and tc7.0.x) I got javax.websocket.DeploymentException: The HTTP response from the server [HTTP/1.1 404 Not Found] did not permit the HTTP upgrade to WebSocket as expected. However, the response processing is a blocking operation and can lead to the wait you describe. Can you isolate the case with a test app? Obviously I'm missing something. Hi Niki, The key differences are: * 2 separate web apps - where the client web app is starting before the server * we are using a custom ClientEndpointConfig and ServerEndpointConfig classes, respectively, because we're passing some additional parameters in the HTTP upgrade headers * the JSR-356 impl is not using annotation, but is using the following: extends Endpoint implements WholeThingworxMessage, ICommunicationChannel Not sure what differences this makes. -bob 1. a socket listening - Hence connections are processed 2. missing application - Hence 404 Not Found status code is expected I expect to have 404 response code on initial upgrade request cheers Niki (sorry for previous partial response, hit send by mistake) ** ** Is this a bug or a known limitation when a client/server in the same webapp try to connect at startup? ** ** Thanks ** ** localhost-startStop-1 daemon prio=6 tid=0x0ef0f800 nid=0x1624 waiting on condition [0x1046e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x0007d6d98b18 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndChec kInt errupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSh ared Interruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShar edIn terruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236 )*** * at sun.nio.ch.PendingFuture.get(PendingFuture.java:180) at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsW e bSocketContainer.java:568) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsW e bSocketContainer.java:317) at com.thingworx.core.communication.channels.jsr356.client.Jsr356Cli entC hannel.connect(Jsr356ClientChannel.java:57) at com.thingworx.core.communication.endpoints.CommunicationEndpoint.con n
possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBaseT.onMessage
Sorry, accidentally posted this to USERS, when it should be here in DEV
I am testing what happens when Encode/Decode Exceptions occur during JSR-356
communication and found that in the following code in onMessage, the
((WsSession)session) is NULL. As a result, the actual DecodeException (cause)
is lost.
// Can this message be decoded?
Object payload;
try {
payload = decode(message);
} catch (DecodeException de) {
((WsSession) session).getLocal().onError(session, de);
return;
}
Tracing this further up the stack, I found that Util.getMessageHandlers is
initializing it and passing NULL in for the session:
if (decoderMatch.getTextDecoders().size() 0) {
MessageHandlerResult result = new MessageHandlerResult(
new PojoMessageHandlerWholeText(listener, m, null,
endpointConfig,
decoderMatch.getTextDecoders(), new Object[1],
0, false, -1, -1),
MessageHandlerResultType.TEXT);
results.add(result);
}
Is this a bug, or do I need to do something else to get this internal session
initialize - in addition to calling: addMessageHandler(this) in the onOpen of
my Endpoint-derived class?
Thanks,
Bob DeRemer
Senior Director, Architecture and Development
[Description: Description: Description: Description:
cid:image001.png@01CBE3DE.51A12030]
http://www.thingworx.comhttp://www.thingworx.com/
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986
Re: [VOTE] Release Apache Tomcat 7.0.47
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
Re: Tomcat closes Websocket connection when using a SSL HTTP APR connector (was: RE: Tagging 7.0.46)
On 18/10/2013 19:37, Mark Thomas wrote: On 18/10/2013 13:54, Mark Thomas wrote: On 18/10/2013 12:48, Mark Thomas wrote: When it goes wrong, the sequence is: Read result [1] Read result [48] Read result [-20014] 18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1] websocket.drawboard.DrawboardEndpoint.onError onError: java.io.IOException: Unexpected error [20,014] reading data from the APR/native socket [364,180,784]. I've dug in to what could trigger the 20014 error code. I've got as far as ssl_socket_recv() in native\src\sslnetwork.c There appear to be a number of ways that the code could end up returning 20014. The next step is to figure out which it is. I've made some progress. I've captured a failure with Wireshark with an SSL configuration that Wireshark can decrypt with the server's private key (SSLProtocol=SSLv3, SSLCipherSuite=RC4-MD5) and it shows nothing unusual until Tomcat initiates the close. To progress I need to create a new tcnative with some debug info so I guess I'll have to return to trying to get my local build environment set up correctly. No joy getting a Windows build environment created but the error also occurs on Linux and I do have a working build environment there. The various errors reported in ssl_socket_recv() are: SSL_READ returns -1 SSL_get_error returns 5 (SSL_ERROR_SYSCALL) apr_get_netos_error returns 11 (APR_STATUS_IS_ENOTSOCK) At this point it looks like the issue is in the tcnative / APR / OpenSSL integration and I am way out of my depth. Looking at the source code for APR reads, the InternalAprInputBuffer uses Socket.recvbb() whereas AprServletInputStream current uses Socket.recv(). My short-term plan is to switch AprServletInputStream to Socket.recvbb() for SSL and see if that fixes the problem. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
