svn commit: r1798561 - /tomcat/trunk/README.md
Author: violetagg Date: Tue Jun 13 06:59:46 2017 New Revision: 1798561 URL: http://svn.apache.org/viewvc?rev=1798561&view=rev Log: Add links to the corresponding documents. Modified: tomcat/trunk/README.md Modified: tomcat/trunk/README.md URL: http://svn.apache.org/viewvc/tomcat/trunk/README.md?rev=1798561&r1=1798560&r2=1798561&view=diff == --- tomcat/trunk/README.md (original) +++ tomcat/trunk/README.md Tue Jun 13 06:59:46 2017 @@ -38,11 +38,11 @@ http://tomcat.apache.org/tomcat-9.0-doc/ ### Installation -Please see RUNNING.txt for more info. +Please see [RUNNING.txt](RUNNING.txt) for more info. ### Licensing -Please see LICENSE for more info. +Please see [LICENSE](LICENSE) for more info. ### Support and Mailing List Information @@ -66,4 +66,4 @@ instructions for reporting a bug ### Contributing -Please see CONTRIBUTING for more info. +Please see [CONTRIBUTING](CONTRIBUTING.md) for more info. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building . Full details are available at: https://ci.apache.org/builders/tomcat-7-trunk/builds/768 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' triggered this build Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1798560 Blamelist: violetagg Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: asyncError() is not valid while in Async state DISPATCHING
Hi, 2017-06-12 21:43 GMT+03:00 Mark Thomas : > > On 09/06/17 16:26, Violeta Georgieva wrote: > > 2017-06-09 17:25 GMT+03:00 Mark Thomas : > > > > >> I've spent some time working through the various possible combinations > >> of events and have concluded it is impossible to completely fix this > >> without imposing additional requirements on applications that the > >> specification doesn't mention. > >> > >> However, I believe that we can do better than the current > >> implementation. What I have on mind would: > >> > >> - always trigger AsyncListener.onError() for all listeners > >> - generally, process the complete() dispatch() call from the > >> AsyncListener rather than any from the non-container thread > >> - generally, throw an ISE if complete() or dispatch() is called > >> from the non-container thread after that thread experiences an I/O > >>error > >> - leave a small timing window where it was possible that the complete() > >> or dispatch() from the non-container thread would be used rather than > >> from the AsyncListener. In that case the AsyncListener would see the > >> ISE but any remaining AsyncListener instances would still be called > >> > >> I don't see a way of doing better than this without spec changes / > >> clarifications. > >> > >> WDYT? > > > > +1 > > I'm able to test the new behavior with my real web app. > > Excellent. I've committed my proposed fix. The async unit tests pass > which is generally a good sign. If this works better with your real web > application then we can look to back-port this. I'm seeing now the following exceptions: java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [MUST_DISPATCH] at org.apache.coyote.AsyncStateMachine.doComplete(AsyncStateMachine.java:317) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AsyncStateMachine.asyncComplete(AsyncStateMachine.java:301) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:377) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.Request.action(Request.java:424) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.catalina.core.AsyncContextImpl.complete(AsyncContextImpl.java:96) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:427) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:176) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:225) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core.jar!/:8.5.16-dev] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core.jar!/:8.5.16-dev] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] == java.lang.NullPointerException: null at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:411) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:176) ~[tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:225) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) [tomcat-embed-core.jar!/:8.5.16-dev] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core.jar!/:8.5.16-dev] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core.jar!/:8.5.16-dev] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] Thanks, Violeta > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev
Re: asyncError() is not valid while in Async state DISPATCHING
2017-06-13 13:04 GMT+03:00 Violeta Georgieva : > > Hi, > > > 2017-06-12 21:43 GMT+03:00 Mark Thomas : > > > > On 09/06/17 16:26, Violeta Georgieva wrote: > > > 2017-06-09 17:25 GMT+03:00 Mark Thomas : > > > > > > > > >> I've spent some time working through the various possible combinations > > >> of events and have concluded it is impossible to completely fix this > > >> without imposing additional requirements on applications that the > > >> specification doesn't mention. > > >> > > >> However, I believe that we can do better than the current > > >> implementation. What I have on mind would: > > >> > > >> - always trigger AsyncListener.onError() for all listeners > > >> - generally, process the complete() dispatch() call from the > > >> AsyncListener rather than any from the non-container thread > > >> - generally, throw an ISE if complete() or dispatch() is called > > >> from the non-container thread after that thread experiences an I/O > > >>error > > >> - leave a small timing window where it was possible that the complete() > > >> or dispatch() from the non-container thread would be used rather than > > >> from the AsyncListener. In that case the AsyncListener would see the > > >> ISE but any remaining AsyncListener instances would still be called > > >> > > >> I don't see a way of doing better than this without spec changes / > > >> clarifications. > > >> > > >> WDYT? > > > > > > +1 > > > I'm able to test the new behavior with my real web app. > > > > Excellent. I've committed my proposed fix. The async unit tests pass > > which is generally a good sign. If this works better with your real web > > application then we can look to back-port this. > > I'm seeing now the following exceptions: I back ported the fix to my local 8.5 branch in order to be able to test it ... > > java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [MUST_DISPATCH] > at org.apache.coyote.AsyncStateMachine.doComplete(AsyncStateMachine.java:317) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AsyncStateMachine.asyncComplete(AsyncStateMachine.java:301) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:377) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.Request.action(Request.java:424) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.catalina.core.AsyncContextImpl.complete(AsyncContextImpl.java:96) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:427) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:176) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:225) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core.jar!/:8.5.16-dev] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core.jar!/:8.5.16-dev] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102] > > > == > > java.lang.NullPointerException: null > at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:411) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:176) ~[tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:225) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) [tomcat-embed-core.jar!/:8.5.16-dev] > at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core.jar!/:8.5.16-dev] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_102] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_102] > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core.
Re: asyncError() is not valid while in Async state DISPATCHING
On 13/06/17 11:05, Violeta Georgieva wrote: > 2017-06-13 13:04 GMT+03:00 Violeta Georgieva : >> >> Hi, >> >> >> 2017-06-12 21:43 GMT+03:00 Mark Thomas : >>> >>> On 09/06/17 16:26, Violeta Georgieva wrote: 2017-06-09 17:25 GMT+03:00 Mark Thomas : >>> >>> >>> > I've spent some time working through the various possible > combinations > of events and have concluded it is impossible to completely fix this > without imposing additional requirements on applications that the > specification doesn't mention. > > However, I believe that we can do better than the current > implementation. What I have on mind would: > > - always trigger AsyncListener.onError() for all listeners > - generally, process the complete() dispatch() call from the > AsyncListener rather than any from the non-container thread > - generally, throw an ISE if complete() or dispatch() is called > from the non-container thread after that thread experiences an I/O >error > - leave a small timing window where it was possible that the > complete() > or dispatch() from the non-container thread would be used rather > than > from the AsyncListener. In that case the AsyncListener would see > the > ISE but any remaining AsyncListener instances would still be called > > I don't see a way of doing better than this without spec changes / > clarifications. > > WDYT? +1 I'm able to test the new behavior with my real web app. >>> >>> Excellent. I've committed my proposed fix. The async unit tests pass >>> which is generally a good sign. If this works better with your real web >>> application then we can look to back-port this. >> >> I'm seeing now the following exceptions: In the same run or different runs? > I back ported the fix to my local 8.5 branch in order to be able to test it > ... > >> >> java.lang.IllegalStateException: Calling [asyncComplete()] is not valid > for a request with Async state [MUST_DISPATCH] It appears the application called dispatch() from a non-container thread once the error state had been entered. We could block that but there is a risk it will break valid use cases. Fundamentally, I don't believe the app should be doing this. >> at > org.apache.coyote.AsyncStateMachine.doComplete(AsyncStateMachine.java:317) > ~[tomcat-embed-core.jar!/:8.5.16-dev] >> == >> >> java.lang.NullPointerException: null Appears to be the same cause as above, but triggered at a different point. >> at > org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:411) > ~[tomcat-embed-core.jar!/:8.5.16-dev] This is consistent with what I'd expect. In both of the above cases any AsyncListener.onError() methods should execute but if the app continues to do things on the non-container thread then there possibility of exceptions remains. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61183] New: Deadlock occurs while sending to a closing session
https://bz.apache.org/bugzilla/show_bug.cgi?id=61183
Bug ID: 61183
Summary: Deadlock occurs while sending to a closing session
Product: Tomcat 8
Version: 8.0.33
Hardware: PC
Status: NEW
Severity: regression
Priority: P2
Component: WebSocket
Assignee: dev@tomcat.apache.org
Reporter: lorc...@live.com
Target Milestone:
Hi,
We have recently ran into a deadlock situation in a customer site while using
websockets.
One of the locks is in our code while the other is the Tomcat "stateLock"
defined in "class WsSession".
I have marked this issue as a regression because one of the 2 locations that
Tomcat takes the stateLock in 8.0.33 did not exist in 8.0.29. Here's a quick
look at the differences before examining the deadlocked call stacks:
In 8.0.33 there's an expansion of the stateLock usage:
protected void registerFuture(FutureToSendHandler f2sh) {
boolean fail = false;
synchronized (stateLock) {
// leaving out the details...
}
}
While in 8.0.29 the entire method looks like:
protected void registerFuture(FutureToSendHandler f2sh) {
futures.put(f2sh, f2sh);
}
I can understand why the stateLock usage has been expanded. But I think there
is a problem with this. Previously we'd only enter stateLock in Tomcat ->
Application calls. Now with the new registerFuture we also can enter stateLock
in Application -> Tomcat calls.
So a recent change seems to have introduced a key ingredient for deadlocks. If
my application has its own lock there is the potential for 2 locks to be
acquired in reverse order by 2 simultaneous threads.
We have experienced a real-world example of this:
In the 1st thread Tomcat is closing the session after an abrupt disconnect from
the client. The close action bubbles up to the Application onClose handler:
"http-nio-8445-exec-76" daemon prio=5 tid=249 BLOCKED
at
com.myc.common.domain.websocketutil.WsOutbound.setSocketStatus(WsOutbound.java:152)
--> Waits on the Application local lock
Local Variable:
com.myc.common.domain.websocketutil.WsOutbound$SocketStatus#2
at
com.myc.customer.web.socket.WebSocketEndpoint.onClose(WebSocketEndpoint.java:224)
--> Application onClose handler called which has to do some tidy up
Local Variable: javax.websocket.CloseReason#2
Local Variable:
com.myc.customer.web.socket.WebSocketEndpoint#4
Local Variable: java.lang.Object#9184
at sun.reflect.GeneratedMethodAccessor250.invoke()
at sun.reflect.DelegatingMethodAccessorImpl.invoke()
at java.lang.reflect.Method.invoke()
at
org.apache.tomcat.websocket.pojo.PojoEndpointBase.onClose(PojoEndpointBase.java:107)
Local Variable:
org.apache.tomcat.websocket.pojo.PojoEndpointServer#6
at
org.apache.tomcat.websocket.WsSession.fireEndpointOnClose(WsSession.java:541)
Local Variable:
org.apache.catalina.loader.WebappClassLoader#2
Local Variable:
org.apache.catalina.core.DefaultInstanceManager#3
at
org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:490)
--> Acquires a “state lock” on Tomcats call to close the session
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.onError(WsHttpUpgradeHandler.java:150)
Local Variable:
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler#6
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.access$300(WsHttpUpgradeHandler.java:48)
In the 2nd thread the Application is simply sending a normal message to Tomcat
(unaware the session is closing simultaneously):
"defaultEventExecutorGroup-3-1" prio=5 tid=94 BLOCKED
at
org.apache.tomcat.websocket.WsSession.registerFuture(WsSession.java:650)
--> Waits on the Tomcat “stateLock”
Local Variable: org.apache.tomcat.websocket.WsSession#6
at
org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:104)
Local Variable:
org.apache.tomcat.websocket.FutureToSendHandler#247
Local Variable: java.util.concurrent.TimeUnit$4#1
at
org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:31)
at
com.myc.common.domain.websocketutil.WsOutbound.await(WsOutbound.java:255)
at
com.myc.common.domain.websocketutil.WsOutbound.sendObj(WsOutbound.java:234)
at
com.myc.common.domain.websocketutil.WsOutbound.send(WsOutbound.java:215)
--> Acquires the Application local lock while sending (to guarantee message
order when sending multiple messages)
Local Variable:
com.myc.customer.model.json.notification.Ne
[Bug 61183] Deadlock occurs while sending to a closing session
https://bz.apache.org/bugzilla/show_bug.cgi?id=61183 --- Comment #1 from Lorcan O'Toole --- Created attachment 35050 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35050&action=edit Description in txt Call stacks and comments might be easier to read with .txt -- 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 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 --- Comment #32 from Remy Maucherat --- Created attachment 35051 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35051&action=edit Test patch for OpenSSL engine As the OpenSSL engine is affected, I guess it's inevitable some SSL session accesses are asynchronous. As a result, sync/cache has to be added. As I am not reproducing it, this is only an experiment patch that can be used for further testing. The APR connector would need something similar as well. The performance impact should be quite minimal. -- 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 61185] New: AsynContext.dispatch() does not use encoded URI
https://bz.apache.org/bugzilla/show_bug.cgi?id=61185 Bug ID: 61185 Summary: AsynContext.dispatch() does not use encoded URI Product: Tomcat 8 Version: 8.5.x-trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: rstoyanc...@yahoo.com Target Milestone: >From the Servlet spec says: "If the AsyncContext was initialized via the startAsync(ServletRequest, ServletResponse) and the request passed is an instance of HttpServletRequest , then the dispatch is to the URI returned by HttpServletRequest.getRequestURI()" However AsyncContextImpl uses the servletPath: https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 So given a URL with an encoded slash (and UDecoder.ALLOW_ENCODED_SLASH=true): /foo/vv%2F1234/add/2 The dispatch ends up going to: /foo/vv/1234/add/2 -- 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
