websocket connection (at startup) between 2 webapps in same Tomcat 7.0.47 instance hangs indefinitely
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: 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 [Description: Description: Description: Description: cid:image001.png@01CBE3DE.51A12030] http://www.thingworx.com<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 wrote: > > > > > > > > > On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer > wrote: > > > >> 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.thingw
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 > wrote: > > > > > > > > -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 > > wrote: > > > > > > > > > > > > > > > > > > > On Sat, Oct 19, 2013 at 12:09 AM, Bob DeRemer > > > wrote: > > > > > > > >> 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 Whole, 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
possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBase.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.com<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: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, October 22, 2013 3:34 PM > To: Tomcat Developers List > Subject: Re: websocket connection (at startup) between 2 webapps in same > Tomcat 7.0.47 instance hangs indefinitely > > On 22/10/2013 16:17, Mark Thomas wrote: > > On 18/10/2013 22:09, Bob DeRemer wrote: > >> 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: > >> > >> > >> > >> Is this a bug or a known limitation when a client/server in the same > >> webapp try to connect at startup? > > > > It certainly shouldn't hang indefinitely - I'll take a look. > > I have fixed the indefinite hang. There is now a user configurable IO timeout > the defaults to 5 seconds. > > If you enable parallel starting of containers (set startStopThreads on the > host to > more than 1) you might be able to work around this but I haven't tested it. > > To avoid random timing issues, you'll still need to handle the failure and > retry > after a short wait. > Outta curiosity, what was going on? Also, will this be in 7.0.48? Thx for such a quick turnaround - bob > Mark > > > > > However, there is no guarantee made about application start order so > > your code will need to handle failures and re-try after a suitable wait. > > > > Mark > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For > > additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional > commands, e-mail: dev-h...@tomcat.apache.org - 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
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, October 22, 2013 4:00 PM > To: Tomcat Developers List > Subject: Re: websocket connection (at startup) between 2 webapps in same > Tomcat 7.0.47 instance hangs indefinitely > > On 22/10/2013 20:41, Bob DeRemer wrote: > > > > > >> -Original Message- > >> From: Mark Thomas [mailto:ma...@apache.org] > >> Sent: Tuesday, October 22, 2013 3:34 PM > >> To: Tomcat Developers List > >> Subject: Re: websocket connection (at startup) between 2 webapps in > >> same Tomcat 7.0.47 instance hangs indefinitely > >> > >> On 22/10/2013 16:17, Mark Thomas wrote: > >>> On 18/10/2013 22:09, Bob DeRemer wrote: > >>>> 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: > >>>> > >>>> > >>>> > >>>> Is this a bug or a known limitation when a client/server in the > >>>> same webapp try to connect at startup? > >>> > >>> It certainly shouldn't hang indefinitely - I'll take a look. > >> > >> I have fixed the indefinite hang. There is now a user configurable IO > >> timeout the defaults to 5 seconds. > >> > >> If you enable parallel starting of containers (set startStopThreads > >> on the host to more than 1) you might be able to work around this but I > haven't tested it. > >> > >> To avoid random timing issues, you'll still need to handle the > >> failure and retry after a short wait. > >> > > > > Outta curiosity, what was going on? Also, will this be in 7.0.48? > > Thx for such a quick turnaround - bob > > All the IO was configured to use infinite timeouts (that would be my fault). > > The client app started, made an HTTP request to initiate the connection. > > The connector was listening on the socket since init() has been called > (default is > to bind on init) but the acceptor thread had not been started so the > connection > was not processed. > > The client then started to block, waiting for the response. > > Since the client was in a ServletContextListener it blocked. That in turn > blocked > the start of the content which in turn blocked the styart sequence. > > Since the start sequence was blocked the connectors were never going to be > started which is when the acceptors start so you had a deadlock. > > The reason it worked when you deployed while Tomcat was running was that > the connectors were all up and running handling connections so nothing > blocked. > > This was never going to work regardless of the order the apps start in because > the acceptor doesn't start until after all the web applications have started. > > Yes, I have just back-ported it to 7.0.48. > > Mark > Excellent - thx > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional > commands, e-mail: dev-h...@tomcat.apache.org - 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
> -Original Message- > From: Violeta Georgieva [mailto:miles...@gmail.com] > Sent: Thursday, October 24, 2013 5:10 AM > To: Tomcat Developers List > Subject: Re: [VOTE] Release Apache Tomcat 7.0.47 > > Hi, > > 2013/10/18 Violeta Georgieva > > > > 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 > > > The votes cast were > > +1 (binding): rjung, markt, olamy > +1 (non-binding): Ognjen Blagojevic, kfujino, violetagg, jfarcand > > No other votes were cast. > > With three binding +1 votes and four non-binding +1 votes this vote passes. > > I'll upload the release to the mirrors and announce it once the mirrors are > OK. > Given some of the recent fixes to 7.0.48 (trunk), should that be tagged for consideration as the target of the RC now? Thx, bob > Regards > Violeta - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[potential?] bug in Tomcat 7's websocket UpgradeUtil when handling concurrent connections that use a custom ServerEndpointConfig.Configurator
First off, this is the 2nd [potential] bug I've reposted from the user list, so
my apologies. After reading the mailing list descriptions, it seems potential
bugs should be posted to the DEV list. If this is wrong, just let me know.
Potential Bug?
I [think] there may be a problem in Tomcat's static UpgradeUtil.doUpgrade logic
when handling concurrent connection/upgrade requests that rely on a custom
ServerEndpointConfig.Configurator.modifyHandshake to grab [per-upgrade-request]
client header values and inject them into the wsSession that is being created.
Specifically, the static doUpgrade does not appear to make a copy of the
ServerEndpointConfig before calling modifyHandshake. As a result, any
per-connection headers the Configurator may grab and put in the
ServerEndpointConfig.UserProperties map will be overwritten by the last upgrade
request that occurs before the upgrade logic creates the new wsSession in the
WsHttpUpgradeHandler.init call.
I am able to replicate this very easily by using the following server
configurator code. By making concurrent websocket connect requests that place
a unique "client-id" in the upgrade request headers, then grabbing that
"client-id" property using the code below, ALL websocket sessions that get
created will have the last "client-id" header value that came in concurrently.
public class Jsr356ServerConfigurator extends ServerEndpointConfig.Configurator
{
@Override
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest
request, HandshakeResponse response)
{
// get the request headers - looking for security claims and
endpoint ID
// claims will be checked in the OnOpen call and the connection
closed if AUTH check fails
Map> headers = request.getHeaders();
String id = headers.get("client-id").get(0);
config.getUserProperties().put("client-id", id);
}
}
@ServerEndpoint(...)
Public class MyServer
{
@OnOpen
public void onOpen(Session session)
{
String id = (String) session.getUserProperties().get("client-id");
_logger.warn("client ID: {}", id);
}
}
Based on chapter 3 of the JSR-356 API document, the actual websocket handshake
process defined in the websocket spec, and the online description of the
process in this stackoverflow link
(http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint/17994303#17994303),
it appears that we should be able to pass per-client information in the
upgrade headers and we should be able to get them into the endpoint INSTANCE's
Session user properties.
If this is a bug, please confirm and I will create a bugzilla entry, as it is
very important that that we be able to do what I've described above.
If this is not a bug, can someone please describe how to obtain per-client
instance data during the websocket handshake/onOpen process?
Thanks,
Bob
RE: [potential?] bug in Tomcat 7's websocket UpgradeUtil when handling concurrent connections that use a custom ServerEndpointConfig.Configurator
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, October 28, 2013 8:53 AM > To: Tomcat Developers List > Subject: Re: [potential?] bug in Tomcat 7's websocket UpgradeUtil when > handling concurrent connections that use a custom > ServerEndpointConfig.Configurator > > On 28/10/2013 12:18, Mark Thomas wrote: > > > I'm going to start work on updating Tomcat just as soon as I finish > > typing this. > > Try now. I've applied to fix to both 8.0.x and 7.0.x for the next release of > each. > > Mark > Thanks for the quick turnaround -bob > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional > commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Any ETA on 7.0.48 vote?
Is a vote on 7.0.48 expected anytime in the near future? Thanks, Bob
Tomcat 7.0.50 status?
The voting so far seems to indicate 7.0.50 is stable, so I wanted to see if there were any further issues keeping it from going GA? If not, when do you anticipate releasing? Thanks, _ ThingWorx, A PTC Company Bob DeRemer, Sr. Director Architecture/Development bob.dere...@thingworx.com<mailto:bob.dere...@thingworx.com> | www.thingworx.com<http://www.thingworx.com/> | www.ptc.com<http://www.ptc.com/> M: 717.881.3986 | O: 610.594.6200 x 812
RE: 8.0.x / 7.0.x progress
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, October 02, 2013 1:28 PM > To: Tomcat Developers List > Subject: Re: 8.0.x / 7.0.x progress > > On 01/10/2013 19:39, Mark Thomas wrote: > > 8.0.x trunk appears to be stable (i.e. no longer crashes) > > So far no-one has come forward with results to contradict this and folks that > reported issues with RC3 have not been able to repeat them. > > The additional issues reported with the snake example have been resolved. > > Currently, the 8.0.x unit tests pass (with tomcat native built from > 1.1.x) for BIO, NIO and APR/native. > > > but the > > FormAuthenticator unit tests are very slow (24 minutes). This needs to > > be resolved. > > This has been resolved. > > > I will port the latest APR changes to 7.0.x shortly. > > Also done. > > > A build of the latest 1.1.x tomcat-native code is required to achieve > > that stability. The implication is that a 1.1.29 release will be > > required before the next 7.0.x release. > > I'm now certain that a tomcat native 1.1.29 release will be required before we > can roll the next 7.0.x release. > > > The unit tests have identified a rare failure mode in JULI during > > context stop: > > http://ci.apache.org/projects/tomcat/tomcat7/logs/1527504/TEST-org.apa > > che.catalina.websocket.TestWebSocket.NIO.txt > > This does not appear to be connector related so it is very unlikely that any > tomcat native changes would be required to fix this. > > > The fairly frequent (5%-10%) failure rate of TestCoyoteOutputStream > > still needs to be addressed. > > This appears to impact all connectors so at this point it is unlikely a tomcat > native change would be required. > > > I think we are at a point where it makes sense to start a tomcat native > 1.1.29 release. Mladen? Please excuse the possibly naïve question, but what does it mean to "start a native release" - in terms of timeline? Is this a build/test cycle, or is there more involved? Just curious what we may be looking at with regard to impact on 7.0 GA. - thx, bob > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional > commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
