RE: META-INF/Context.xml path question

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, January 13, 2014 3:16 PM
> To: Tomcat Users List
> Subject: Re: META-INF/Context.xml path question
> 
> On 13/01/2014 17:38, Bob DeRemer wrote:
> > We're trying to determine if it's possible to build a WAR with an
> > embedded META-INF/Context.xml
> 
> It is context.xml, not Context.xml. Case matters.
> 
> > that defines the webapp path to be
> > different then the WAR file name.
> 
> No, it is not possible to do this.
> 
> >   Let's say we have
> > AppServer-.war, but we want to access it as:
> > http:///Server.   In addition, we want to support
> > uploading/installing the WAR both from the Manager app as well as
> > using ftp/command-line to copy the WAR and restart Tomcat.  This way,
> > it's pretty much automatic without editing/creating additional XML
> > files.
> >
> > If this works, then we can have identifiable WAR files, but with a
> > common/standard webapp path.
> 
> The way to have identifiable WARs is to use the version element of the
> filename. For example, server##1.0.15.war will be auto-deployed with a
> context path of /server. The version tag can be pretty much anything you like 
> as
> long as the file name is valid. You don't have to be using parallel 
> deployment to
> make use of it.

version syntax works great, thx

> 
> > We have reviewed the docs and the only approach that has worked for us
> > is adding a separate Context element to the /conf/Server.xml
> > file.
> 
> It is server.xml. Again, case matters.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

META-INF/Context.xml path question

[Bob DeRemer]

We're trying to determine if it's possible to build a WAR with an embedded 
META-INF/Context.xml that defines the webapp path to be different then the WAR 
file name.   Let's say we have AppServer-.war, but we want to access 
it as: http:///Server.   In addition, we want to support 
uploading/installing the WAR both from the Manager app as well as using 
ftp/command-line to copy the WAR and restart Tomcat.  This way, it's pretty 
much automatic without editing/creating additional XML files.

If this works, then we can have identifiable WAR files, but with a 
common/standard webapp path.

We have reviewed the docs and the only approach that has worked for us is 
adding a separate Context element to the /conf/Server.xml file.

Thanks,

_
ThingWorx, a PTC owned 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: high CPU usage with NIO and 1000+ websockets on Tomcat 7.0.49?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Saturday, December 14, 2013 9:06 AM
> To: Tomcat Users List
> Subject: Re: high CPU usage with NIO and 1000+ websockets on Tomcat 7.0.49?
> 
> On 13/12/2013 13:12, Bob DeRemer wrote:
> > We have been profiling this in YourKit and as we increase the number
> > of websockets, naturally we see the CPU utilization increase.  The
> > concern is that we're seeing this at what seems to be a fairly low
> > number of websockets.  The YourKit profiling showed 41% of the time
> > being spent in the following code.  My apologies for the formatting.
> > I can provide an attachment out-of-band if it would be helpful.
> 
> I've seen similar figures from YourKit when testing with just a single
> connection. There does seem to be a lot of time spent in the NIO Poller code.
> 
> When I looked at it last time nothing immediately obvious jumped out at me in
> terms of something that could be changed to improve things. It needs some
> more time spent on a deeper analysis. That is on my TODO list. If any NIO
> experts want to take a look and make some suggestions that would be great.
> 
> As an aside, as much as I like YourKit, you do have to be careful (as you do 
> with
> any profiler) when stress testing that the profiler isn't distorting the 
> results. I
> have been led down the wrong path a few times when I wasn't careful enough.
> 

I have noticed about a 20% reduction in performance using Yourkit in it's least 
intrusive mode.  Thanks for the input and suggestions.  If I find out anything 
additional, I'll post it.

Thx, bob

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


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

high CPU usage with NIO and 1000+ websockets on Tomcat 7.0.49?

[Bob DeRemer]

 |  11,746   12 %  |  0  |
|  | | | |   |  
  | | |
|  | | | |   +---java.util.concurrent.ThreadPoolExecutor.execute(Runnable)  
  |  11,746   12 %  | 15  |
|  | | | | |
  | | |
|  | | | | +---org.apache.tomcat.util.threads.TaskQueue.offer(Object)   
  |  11,731   12 %  |  0  |
|  | | | |   |  
  | | |
|  | | | |   
+---org.apache.tomcat.util.threads.TaskQueue.offer(Runnable)
 |  11,731   12 %  | 46  |
|  | | | | |
  | | |
|  | | | | 
+---java.util.concurrent.LinkedBlockingQueue.offer(Object)  
   |  11,668   12 %  | 15  |









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: seeing RemoteEndpoint.Basic BINARY_FULL_WRITING errors under load in Tomcat 7.0.48-dev (trunk)

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, November 27, 2013 12:59 PM
> To: Tomcat Users List
> Subject: Re: seeing RemoteEndpoint.Basic BINARY_FULL_WRITING errors under
> load in Tomcat 7.0.48-dev (trunk)
> 
> On 27/11/2013 17:28, Bob DeRemer wrote:
> > When testing our WebSocket application under heavy load we eventually get
> the following exception from the JSR-356 ServerEndpoint's
> RemoteEndpoint.Basic when trying to write our binary response message:
> >
> > java.lang.IllegalStateException: The remote endpoint was in state
> [BINARY_FULL_WRITING] which is an invalid state for called method
> >at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.chec
> kState(WsRemoteEndpointImplBase.java:1048) ~[tomcat7-
> websocket.jar:7.0.48-dev]
> >at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.bina
> ryStart(WsRemoteEndpointImplBase.java:1001) ~[tomcat7-
> websocket.jar:7.0.48-dev]
> >at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendBytes(WsRemo
> teEndpointImplBase.java:118) ~[tomcat7-websocket.jar:7.0.48-dev]
> >at
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendBinary(WsRemote
> EndpointBasic.java:43) ~[tomcat7-websocket.jar:7.0.48-dev]
> >at
> com.thingworx.communications.server.connection.Jsr356ServerConnection.sen
> dBinaryMessage(Jsr356ServerConnection.java:240) ~[thingworx-server-
> common.jar:na]
> >at
> com.thingworx.communications.common.endpoints.CommunicationEndpoint.se
> ndBinaryMessage(CommunicationEndpoint.java:321) ~[thingworx-server-
> common.jar:na]
> >at
> com.thingworx.communications.common.endpoints.CommunicationEndpoint.se
> ndMessage(CommunicationEndpoint.java:303) ~[thingworx-server-
> common.jar:na]
> >at
> com.thingworx.apiserver.endpoints.RoutingServerEndpoint.sendMessage(Routi
> ngServerEndpoint.java:24) ~[thingworx-apiserver.jar:na]
> >at
> com.thingworx.apiserver.routing.OutboundMessageRoutingTask.run(Outbound
> MessageRoutingTask.java:79) ~[thingworx-apiserver.jar:na]
> >at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1
> 145) [na:1.7.0_45]
> >at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
> 615) [na:1.7.0_45]
> >at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
> >
> > The Tomcat build is 7.0.48-dev (from today, 11/27) and we're running on
> Ubuntu Server 13.10 in EC2 (16 vCPUs).  The client created 1000 concurrent
> websockets, and is using 100 threads to send 100 concurrent requests every 3
> ms.  The server receives the messages, processes them, then sends the
> response back to the appropriate client.  Many response are sent successfully,
> but after some period of time, we start receiving the above errors when
> attempting to send the responses back.
> >
> > Is it possible that we could be filling up the TCP buffers (or something 
> > related)
> and this would cause the above exception?
> 
> What can cause the above exception is if the previous message on that
> endpoint failed with an IOException. The nature of WebSocket is such that once
> this happens the only option is to close the connection and start a new one.
> 

It appears that we are getting the following IOException:

java.io.IOException: java.util.concurrent.TimeoutException immediately before 
we got the BINARY_FULL_WRITING errors.  

Would this TimeoutException be caused because the underlying socket did not 
receive an ACK for the sent websocket message, or could something else cause 
this when trying to write to the websocket?

Thx - bob

> > Please note: we lock around a specific ServerEndpoint's
> RemoteEndpoint.Basic - to make sure we aren't trying to send more than 1
> message at a time.
> >
> > Please let me know if this is a bug, or if you need additional information.
> 
> A bug is always possible but at this point it looks like some error handling 
> is
> missing in the app.
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

seeing RemoteEndpoint.Basic BINARY_FULL_WRITING errors under load in Tomcat 7.0.48-dev (trunk)

[Bob DeRemer]

When testing our WebSocket application under heavy load we eventually get the 
following exception from the JSR-356 ServerEndpoint's RemoteEndpoint.Basic when 
trying to write our binary response message:

java.lang.IllegalStateException: The remote endpoint was in state 
[BINARY_FULL_WRITING] which is an invalid state for called method
   at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1048)
 ~[tomcat7-websocket.jar:7.0.48-dev]
   at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.binaryStart(WsRemoteEndpointImplBase.java:1001)
 ~[tomcat7-websocket.jar:7.0.48-dev]
   at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendBytes(WsRemoteEndpointImplBase.java:118)
 ~[tomcat7-websocket.jar:7.0.48-dev]
   at 
org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendBinary(WsRemoteEndpointBasic.java:43)
 ~[tomcat7-websocket.jar:7.0.48-dev]
   at 
com.thingworx.communications.server.connection.Jsr356ServerConnection.sendBinaryMessage(Jsr356ServerConnection.java:240)
 ~[thingworx-server-common.jar:na]
   at 
com.thingworx.communications.common.endpoints.CommunicationEndpoint.sendBinaryMessage(CommunicationEndpoint.java:321)
 ~[thingworx-server-common.jar:na]
   at 
com.thingworx.communications.common.endpoints.CommunicationEndpoint.sendMessage(CommunicationEndpoint.java:303)
 ~[thingworx-server-common.jar:na]
   at 
com.thingworx.apiserver.endpoints.RoutingServerEndpoint.sendMessage(RoutingServerEndpoint.java:24)
 ~[thingworx-apiserver.jar:na]
   at 
com.thingworx.apiserver.routing.OutboundMessageRoutingTask.run(OutboundMessageRoutingTask.java:79)
 ~[thingworx-apiserver.jar:na]
   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
[na:1.7.0_45]
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
[na:1.7.0_45]
   at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]

The Tomcat build is 7.0.48-dev (from today, 11/27) and we're running on Ubuntu 
Server 13.10 in EC2 (16 vCPUs).  The client created 1000 concurrent websockets, 
and is using 100 threads to send 100 concurrent requests every 3 ms.  The 
server receives the messages, processes them, then sends the response back to 
the appropriate client.  Many response are sent successfully, but after some 
period of time, we start receiving the above errors when attempting to send the 
responses back.

Is it possible that we could be filling up the TCP buffers (or something 
related) and this would cause the above exception?

Please note: we lock around a specific ServerEndpoint's RemoteEndpoint.Basic - 
to make sure we aren't trying to send more than 1 message at a time.

Please let me know if this is a bug, or if you need additional information.

Thanks,
Bob

RE: (working) high load (100K+) websocket + NIO connector setting comparison on 1 Tomcat 7 instance

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, November 07, 2013 1:52 PM
> To: Tomcat Users List
> Subject: Re: (working) high load (100K+) websocket + NIO connector setting
> comparison on 1 Tomcat 7 instance
> 
> On 07/11/2013 18:20, Bob DeRemer wrote:
> > Guys,
> >
> > I wanted to follow back around on some of the websocket load testing
> > we've been doing in EC2.The good news is, we were able to get 100K
> > websockets connected directly to a single Tomcat instance (EASILY)
> 
> Excellent.
> 
> > My theory is it's a combination of: acceptorThreadCount
> 
> I find that unlikely as I have explained previously. The lock on
> Socket.accept() quickly becomes the bottleneck above 2 acceptor threads.
> 
> > maxKeepAliveRequests
> 
> Very unlikely to be a factor. There is only a single HTTP request before the
> upgrade to WebSocket so there will never be multiple HTTP requests on a
> single connection so HTTP keep-alive will not be a factor.
> 
> You'd need to test each setting individually to be sure. Some possible
> theories:
> - acceptorThreadCount does have an impact
> - the code implementing maxConnections is the bottleneck - disabling it
> removes it
> - there is a bug in maxConnections that causes it to count connections more
> than once - disabling it avoids the bug
> - connections were timing out due to non-fair processing in socket.accept(), 
> the
> volume of new connections and the time taken to process them - increasing the
> timeout fixed this
> 
> I'd be interested to know which setting it was but without some real world
> testing all we are ever going to have is theories.
> 
> For the benefit of the archives - these settings worked for this test on this
> system. That does not mean they are the best settings for every app on every
> possible combination of hardware. The only way to know the best settings for
> your app on your hardware is to test it.
> 

Understood and agree that this worked in [our] scenario - thanks for the 
analysis.
-bob


> Mark
> 
> 
> 
> > ORIGINAL SETTINGS
> >
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > connectionTimeout="2"
> > maxConnections="10"
> > maxThreads="10"
> > redirectPort="8443" />
> >
> >
> >
> > After looking at the Tomcat Connector documentation closer, along with
> > what Glassfish recommends when deploying in production, we modified
> > the settings to the values shown below:
> >
> >
> >
> > WORKING SETTINGS
> >
> >   >
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >
> >  acceptorThreadCount="8"
> >
> >  maxKeepAliveRequests="-1"
> >
> >  connectionTimeout="-1"
> >
> >  maxConnections="-1"
> >
> >  maxThreads="2"
> >
> >  redirectPort="443" />
> >
> >
> >
> >
> >
> >
> >
> > *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
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

(working) high load (100K+) websocket + NIO connector setting comparison on 1 Tomcat 7 instance

[Bob DeRemer]

Guys,

I wanted to follow back around on some of the websocket load testing we've been 
doing in EC2.The good news is, we were able to get 100K websockets 
connected directly to a single Tomcat instance (EASILY) - once we got the 
settings right.  As a result, I wanted to post my results here for 2 reasons:


1)  Hopefully this may benefit others

2)  I'd like ask the Tomcat experts which of the changes we made is most 
likely to have contributed to this working, or is it a combination?

My theory is it's a combination of: acceptorThreadCount + maxKeepAliveRequests. 
  Logically, it would make sense that running on with 16vCPU(s) should benefit 
from more acceptor threads.  In addition, reading the maxKeepAliveRequests, we 
wondered if making this UNLIMITED would help when many concurrent websocket 
requests come in because they are all HTTP requests initially that get upgraded.

So, if anyone can clarify whether our theory is correct; or, if not - what 
settings below actually made the difference, that would be great!   Without an 
understanding of what Tomcat is doing under the hood, my theory is just that.

Thanks for all the support you guys provide on this list,
Bob


SUMMARY:
I posted earlier this week about having trouble just getting 10 - 20K 
websockets connected to a single Tomcat instance running on a 16vCPU/60GB EC2 
instance running JVM (G1GC, NUMA, 24G - 48G).   The settings during those tests 
were the following, and we were seeing websocket connects fail due to 
TimeoutExceptions and EOFExceptions.

ORIGINAL SETTINGS



After looking at the Tomcat Connector documentation closer, along with what 
Glassfish recommends when deploying in production, we modified the settings to 
the values shown below:

WORKING SETTINGS
 



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: Tomcat 7.0.48 JSR-356 Server (appears ??) to be closing websockets under heavy load with REASON (1006) "network name is no longer available"

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Wednesday, November 06, 2013 1:41 PM
> To: Tomcat Users List
> Subject: Tomcat 7.0.48 JSR-356 Server (appears ??) to be closing websockets
> under heavy load with REASON (1006) "network name is no longer available"
> 
> BACKGROUND:
> We've been load testing our websocket implementation running behind EC2
> ELB.  The ELB is using 4 LARGE EC2 instances we have running Tomcat with our
> websocket implementation.  We have each Tomcat configured with the
> following settings:
> 
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>connectionTimeout="2"
>maxConnections="-1"
>maxThreads="1"
>redirectPort="443" />
> 
> NOTES about our ELB configuration:
> 
> * It was pre-warmed up for 100K+ tcp connections 4 days ago, so it's 
> not a
> scale issue in ELB
> 
> * In addition, we had them increase IDLE connection time to 15 mins - 
> as
> we already hit that problem since we hadn't incorporated a PING yet
> 
> 
> When we fire up 4 separate client machines - each one creating/connecting
> 25K jsr-356 websockets, they all connect through the ELB.  Once connected, we
> have an Executor that will use a configurable number of threads (usually 50 -
> 100).  Each thread will grab a websocket from a queue, delay some specified
> time, then send a message.  Upon success, it puts the websocket back on the
> queue.  The executor threads continue round-robin style until all websockets
> have sent the specified number messages.  The test program then closes all
> websockets, prints stats and exits.
> 
> PROBLEM:
> The problem we saw last night during a run was that after some period of time,
> the client websocket(s) OnClose received the following:
> CloseReason: code [1006], reason [The specified network name is no longer
> available.
> 
> AT this point, we can no longer send, so our test considers that websocket to 
> be
> aborted.
> 
> QUESTION:
> Is anyone aware of what could cause this CloseReason client-side?  Can an
> underlying client-side problem cause this, or would this be something caused 
> by
> the Tomcat server closing the connection for some reason?  I ask because it
> sounds "possibly" similar to the following - even though this was received
> client-side and to our knowledge, the ELB did not close our connection.
> 
> [Bug 55170] New: [websocket][jsr 356]Thread falls in endless cycle when
> connection is reset
> 

UPDATE: after some further investigation, it appears that 1 of the EC2 
instances failed the health check, which is just an empty servlet call right 
now.  
This would result in ALL connections to THAT specific instance being closed, so 
that explains the closes.

The mystery is HOW 5 consecutive calls to an empty servlet (/Health) could all 
fail when the machine was not even close to any capacity (CPU, threads, 
memory).  I'm gonna check the access valve log to see if that shows anything.  

* if anyone has any other suggestions on what may have happened or things to 
check, it would be appreciated.

Thanks
-bob

> Thanks,
> Bob
> 
> http://www.thingworx.com<http://www.thingworx.com/>
> Skype: bob.deremer.thingworx
> O: 610.594.6200 x812
> M: 717.881.3986


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

Tomcat 7.0.48 JSR-356 Server (appears ??) to be closing websockets under heavy load with REASON (1006) "network name is no longer available"

[Bob DeRemer]

BACKGROUND:
We've been load testing our websocket implementation running behind EC2 ELB.  
The ELB is using 4 LARGE EC2 instances we have running Tomcat with our 
websocket implementation.  We have each Tomcat configured with the following 
settings:



NOTES about our ELB configuration:

* It was pre-warmed up for 100K+ tcp connections 4 days ago, so it's 
not a scale issue in ELB

* In addition, we had them increase IDLE connection time to 15 mins - 
as we already hit that problem since we hadn't incorporated a PING yet


When we fire up 4 separate client machines - each one creating/connecting 25K 
jsr-356 websockets, they all connect through the ELB.  Once connected, we have 
an Executor that will use a configurable number of threads (usually 50 - 100).  
Each thread will grab a websocket from a queue, delay some specified time, then 
send a message.  Upon success, it puts the websocket back on the queue.  The 
executor threads continue round-robin style until all websockets have sent the 
specified number messages.  The test program then closes all websockets, prints 
stats and exits.

PROBLEM:
The problem we saw last night during a run was that after some period of time, 
the client websocket(s) OnClose received the following:
CloseReason: code [1006], reason [The specified network name is no longer 
available.

AT this point, we can no longer send, so our test considers that websocket to 
be aborted.

QUESTION:
Is anyone aware of what could cause this CloseReason client-side?  Can an 
underlying client-side problem cause this, or would this be something caused by 
the Tomcat server closing the connection for some reason?  I ask because it 
sounds "possibly" similar to the following - even though this was received 
client-side and to our knowledge, the ELB did not close our connection.

[Bug 55170] New: [websocket][jsr 356]Thread falls in endless cycle when 
connection is reset

Thanks,
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

RE: Is the Tomcat JSR-356 WebSocketClient-AsyncIO threadpool configurable?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, November 06, 2013 1:06 PM
> To: Tomcat Users List
> Subject: Re: Is the Tomcat JSR-356 WebSocketClient-AsyncIO threadpool
> configurable?
> 
> On 06/11/2013 18:01, Bob DeRemer wrote:
> >
> >
> >> -Original Message- From: Mark Thomas
> >> [mailto:ma...@apache.org] Sent: Wednesday, November 06, 2013 12:46 PM
> >> To: Tomcat Users List Subject: Re: Is the Tomcat JSR-356
> >> WebSocketClient-AsyncIO threadpool configurable?
> >>
> >> On 06/11/2013 17:07, Bob DeRemer wrote:
> >>> As part of loading testing our JSR-356 websocket implementation
> >>> (running in Tomcat 7.0.48), we've created a subset of Tomcat jars to
> >>> use as our "client" jsr-356 jars.
> >>>
> >>> Q1: are there any plans to create a client jsr-356 jar - similar to
> >>> the Tyrus RI?
> >>
> >> No. It wouldn't be that hard but you could just use the current JARs.
> >> The server classes don't add that much.
> >>
> >>> Secondly, during this load testing, we have experienced occasional
> >>> IO-related issues that we can't quite pin down, but they all seem to
> >>> be client-side.  Usually, this occurs when we have 20K (or more)
> >>> websocket connections in the test client.
> >>> NOTE:  we are only using 50 - 100 threads in an executor against the
> >>> collection of open websockets, so it doesn't seem like a huge number
> >>> of threads sending/receiving messages.
> >>>
> >>> If appears that Tyrus supports configuration of the client side
> >>> threadpool, but we're currently running on Tomcat in the server, so
> >>> we wanted to find out if the "receiving" threads
> >>> (WebSocketClient-AsyncIO) is coming from the same NIO connector
> >>> threadpool, or from somewhere else.
> >>>
> >>> Q2: is the underlying AsynchronousSocketChannel receiving threadpool
> >>> configurable?
> >>>
> >>> -  when running as a standalone java se client app
> >>>
> >>> -  and, when running within Tomcat as a websocket server
> >>
> >> It is a separate thread pool and is non-configurable. It is,
> >> essentially, unlimited. AsynchronousSocketChannel has a default
> >> AsynchronousChannelGroup (which provides the threads) and Tomcat uses
> >> a custom one that mimics the default with the exception that it sets
> >> a useful thread name.
> >>
> >
> > Thanks.  One final clarification: when creating the thread pool, what
> > are the MIN/MAX thread values, as well as the backing Queue size?  I
> > ask because Java's default behavior will use MIN threads to start.
> > If all threads are busy, it will QUEUE up to max queue size.  Only if
> > it exceeds max queued requests does it start adding more threads.
> > Didn't know if it would be possible to overload the MIN threads and
> > start queueing up inbound websocket messages.
> 
> ExecutorService executorService = new ThreadPoolExecutor(
> 0,
> Integer.MAX_VALUE,
> Long.MAX_VALUE, TimeUnit.MILLISECONDS,
> new SynchronousQueue(),
> new AsyncIOThreadFactory());
> 

Ah, the SyncQueue - so effectively no queueing

thx

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


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

RE: Is the Tomcat JSR-356 WebSocketClient-AsyncIO threadpool configurable?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, November 06, 2013 12:46 PM
> To: Tomcat Users List
> Subject: Re: Is the Tomcat JSR-356 WebSocketClient-AsyncIO threadpool
> configurable?
> 
> On 06/11/2013 17:07, Bob DeRemer wrote:
> > As part of loading testing our JSR-356 websocket implementation
> > (running in Tomcat 7.0.48), we've created a subset of Tomcat jars to
> > use as our "client" jsr-356 jars.
> >
> > Q1: are there any plans to create a client jsr-356 jar - similar to
> > the Tyrus RI?
> 
> No. It wouldn't be that hard but you could just use the current JARs.
> The server classes don't add that much.
> 
> > Secondly, during this load testing, we have experienced occasional
> > IO-related issues that we can't quite pin down, but they all seem to
> > be client-side.  Usually, this occurs when we have 20K (or more)
> > websocket connections in the test client.  NOTE:  we are only using
> > 50 - 100 threads in an executor against the collection of open
> > websockets, so it doesn't seem like a huge number of threads
> > sending/receiving messages.
> >
> > If appears that Tyrus supports configuration of the client side
> > threadpool, but we're currently running on Tomcat in the server, so we
> > wanted to find out if the "receiving" threads
> > (WebSocketClient-AsyncIO) is coming from the same NIO connector
> > threadpool, or from somewhere else.
> >
> > Q2: is the underlying AsynchronousSocketChannel receiving threadpool
> > configurable?
> >
> > -  when running as a standalone java se client app
> >
> > -  and, when running within Tomcat as a websocket server
> 
> It is a separate thread pool and is non-configurable. It is, essentially, 
> unlimited.
> AsynchronousSocketChannel has a default AsynchronousChannelGroup (which
> provides the threads) and Tomcat uses a custom one that mimics the default
> with the exception that it sets a useful thread name.
> 

Thanks.  One final clarification: when creating the thread pool, what are the 
MIN/MAX thread values, as well as the backing Queue size?  I ask because Java's 
default behavior will use MIN threads to start.  If all threads are busy, it 
will QUEUE up to max queue size.  Only if it exceeds max queued requests does 
it start adding more threads.  Didn't know if it would be possible to overload 
the MIN threads and start queueing up inbound websocket messages.


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


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

Is the Tomcat JSR-356 WebSocketClient-AsyncIO threadpool configurable?

[Bob DeRemer]

As part of loading testing our JSR-356 websocket implementation (running in 
Tomcat 7.0.48), we've created a subset of Tomcat jars to use as our "client" 
jsr-356 jars.

Q1: are there any plans to create a client jsr-356 jar - similar to the Tyrus 
RI?

Secondly, during this load testing, we have experienced occasional IO-related 
issues that we can't quite pin down, but they all seem to be client-side.  
Usually, this occurs when we have 20K (or more) websocket connections in the 
test client.  NOTE:  we are only using 50 - 100 threads in an executor against 
the collection of open websockets, so it doesn't seem like a huge number of 
threads sending/receiving messages.

If appears that Tyrus supports configuration of the client side threadpool, but 
we're currently running on Tomcat in the server, so we wanted to find out if 
the "receiving" threads (WebSocketClient-AsyncIO) is coming from the same NIO 
connector threadpool, or from somewhere else.

Q2: is the underlying AsynchronousSocketChannel receiving threadpool 
configurable?

-  when running as a standalone java se client app

-  and, when running within Tomcat as a websocket server

Thanks,
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

RE: Can Tomcat 7 jsr-356 plumbing be configured to automatically send websocket ping/pong on a specified interval?

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Sunday, November 03, 2013 8:31 PM
> To: Tomcat Users List
> Subject: Can Tomcat 7 jsr-356 plumbing be configured to automatically send
> websocket ping/pong on a specified interval?
> 
> During our testing of large scale websocket connections going through Amazon
> ELB, we've found that ELB will timeout idle TCP connections after 60 seconds.
> Our testing scenarios is one where we want to ramp up 10(s) of 1000s of
> websocket connections - then, after they are all connected, start them sending
> request/response messages for some specified duration.
> 
> To avoid ELB closing our connection, we'd like to see if we can configure the
> tomcat plumbing to automatically send ping(s) on some interval.  And, the
> follow-up question: if we can have a ping being sent automatically, will the
> other end of the pipe respond with a pong?
> 
> Thanks,
> Bob

FOLLOW-UP: will the Ping message be sent if an empty byte[] is passed, or must 
it contain at least 1 byte?

> 
> http://www.thingworx.com<http://www.thingworx.com/>
> Skype: bob.deremer.thingworx
> O: 610.594.6200 x812
> M: 717.881.3986


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

Can Tomcat 7 jsr-356 plumbing be configured to automatically send websocket ping/pong on a specified interval?

[Bob DeRemer]

During our testing of large scale websocket connections going through Amazon 
ELB, we've found that ELB will timeout idle TCP connections after 60 seconds.  
Our testing scenarios is one where we want to ramp up 10(s) of 1000s of 
websocket connections - then, after they are all connected, start them sending 
request/response messages for some specified duration.

To avoid ELB closing our connection, we'd like to see if we can configure the 
tomcat plumbing to automatically send ping(s) on some interval.  And, the 
follow-up question: if we can have a ping being sent automatically, will the 
other end of the pipe respond with a pong?

Thanks,
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

RE: weird behavior using Tomcat 7 JSR-356 client implementation in standalone multi-threaded test client

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Sunday, November 03, 2013 11:24 AM
> To: Tomcat Users List
> Subject: Re: weird behavior using Tomcat 7 JSR-356 client implementation in
> standalone multi-threaded test client
> 
> On 03/11/2013 02:29, Bob DeRemer wrote:
> > BACKGROUND: We've created a test client that spins up multiple
> > websocket clients - each in their own thread.  While using their own
> > thread isn't very resource efficient, that's ok.  We want each
> > client's send/receive to be isolated from each other.   Our client
> > logic is using a JSR356 client that extends Endpoint and implements
> > Whole.  In addition, we have message synchronization, so each
> > client will not send a new request until it's received the
> > corresponding respone (i.e. we have our own req/resp messages with
> > unique IDs).
> >
> > Our client is running the JVM with the following: java -Dserver -Dd64
> > -Xms24G -Xmx48g -XX:+UseNUMA -XX:+UseG1GC
> >
> > PROBLEM We are seeing a problem when running multiple clients.   It
> > appears that we're sending messages on 1 websocket client, but
> > sometimes receiving the message on a different websocket.   It can be
> > as little as 1000 or as many as 25000.  It seems to depend on how fast
> > responses are received whether we see the problem.  We have checked
> > the server logging and have verified that all messages have been
> > received and sent back on the proper websocket connection.
> >
> > QUESTION When using Tomcat's JSR-356 client implementation in a
> > standalone java app, what kind of threading does it use under the hood
> > when messages are received?  Is there any possibility that there can
> > be any cross-talk?
> 
> The client uses AsynchronousSocketChannel under the covers. It maintains its
> own thread pool although Tomcat provides a thread factory so the threads get
> sensible names. Each incoming block of data should be processed with a
> separate thread.
> 
> Much of the code is shared between the client and server implementations.
> 
> I don't see any obvious chances for cross-talk. Is the error (when it
> occurs) consistent? ie. client 4 always gets client 5's responses or is it 
> random?
> Consistent would point to an issue during connection setup, random to an issue
> during connection processing.
> 
> It is certainly possible that there is a Tomcat bug here. If it is hard to 
> reproduce
> then code inspection might find it but we need to narrow down the area to look
> in. Keep in mind it could be a client bug too.
> 
> When it occurs, it would be worth checking the clients concerned. E.g.
> have the managed to end up with the same message handler for instance.
> 
> Mark
> 

Thanks Mark - yeah, we haven't ruled out our client code yet, so we're going to 
make sure that's as simple as possible.  If we can come up with a somewhere 
reproducible case, we'll post back.
-bob

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


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

weird behavior using Tomcat 7 JSR-356 client implementation in standalone multi-threaded test client

[Bob DeRemer]

BACKGROUND:
We've created a test client that spins up multiple websocket clients - each in 
their own thread.  While using their own thread isn't very resource efficient, 
that's ok.  We want each client's send/receive to be isolated from each other.  
 Our client logic is using a JSR356 client that extends Endpoint and implements 
Whole.  In addition, we have message synchronization, so each client 
will not send a new request until it's received the corresponding respone (i.e. 
we have our own req/resp messages with unique IDs).

Our client is running the JVM with the following:
java -Dserver -Dd64 -Xms24G -Xmx48g -XX:+UseNUMA -XX:+UseG1GC

PROBLEM
We are seeing a problem when running multiple clients.   It appears that we're 
sending messages on 1 websocket client, but sometimes receiving the message on 
a different websocket.   It can be as little as 1000 or as many as 25000.  It 
seems to depend on how fast responses are received whether we see the problem.  
We have checked the server logging and have verified that all messages have 
been received and sent back on the proper websocket connection.

QUESTION
When using Tomcat's JSR-356 client implementation in a standalone java app, 
what kind of threading does it use under the hood when messages are received?  
Is there any possibility that there can be any cross-talk?

NOTE: we're using the following jar(s) in our standalone client:
tomcat7-websocket.jar
tomcat-api.jar
tomcat-coyote.jar
tomcat-i18n-es.jar
tomcat-util.jar
websocket-api.jar
tomcat-juli.jar


Thanks
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

RE: attempting to achieve 100K concurrent websocket connections on Tomcat 7.0.48 NIO

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, November 01, 2013 7:16 PM
> To: Tomcat Users List
> Subject: Re: attempting to achieve 100K concurrent websocket connections on
> Tomcat 7.0.48 NIO
> 
> On 01/11/2013 22:00, Bob DeRemer wrote:
> > QUESTION: I'm looking for some advice on what Tomcat NIO connector
> > settings to use to support 100K concurrent websocket connections.
> > Hopefully I  can reach this goal through a combination of Tomcat NIO
> > Connector settings, and Server 2008 R2 configuration [if needed].
> >
> > BACKGROUND: We're scale testing our websocket application and looking
> > to see how many concurrent websocket connections we can get on a
> > single Tomcat instance - with the goal being 100K.  I've provided the
> > test landscape details at the bottom - all VERY BIG EC2 instances over
> > 10 GB network, so memory, CPU and network do not appear to be the
> > problem when monitoring.
> >
> > PROBLEM: The problem we are running into is that we can't seem to
> > establish even 50K connections into Tomcat.  At some point, we start
> > getting connect failures, similar to the following:
> 
> OK. Win 2k8 R2, 16GB RAM, bunch of other stuff running, client and server on
> same machine, no tuning. I get 16,313 connections before it falls over. That 
> is
> consistent with the defaults which should allow a maximum of 16384 (given I
> have other stuff running).
> 
> (I'll commit the test to trunk shortly).
> 
> After
> netsh int ipv4 set dynamicport tcp start=1 num=55536
> 
> I got as far as 25121 before I hit GC issues.
> 
> -Xmx12G -Xms12G fixed the GC problems (well, I say fixed allowed them to be
> ignored would be closer)
> 
> The next run got to 55464 connections which looks to be about the limit of the
> ephemeral ports.
> 
> > I'm hoping that someone may be able to advise what changes we might
> > make to the following Tomcat NIO connector setting that will allow
> > upwards of 100K websocket connections:
> >
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > connectionTimeout="2" maxConnections="10"
> > maxThreads="10" redirectPort="8443" />
> 
> As Chris said the threads are probably too high.
> 
> You can set maxThreads="-1" for unlimited connections (worth doing for
> testing).
> 
> > TEST LANDSCAPE:
> >
> > The test landscape is all Windows Server 2008 R2 boxes running in EC2
> > and the Test Client environment:
> >
> > Our test client is a multi-threaded java client that makes use of the
> > JSR356 ClientEndpoint functionality.  We're creating 40K+ websocket
> > connections from a single test client machine.  The test client is
> > Server 2008 R2 and we have configured it to allow 50K ephemeral ports,
> > so we should be able to establish 40K+ outbound websocket connections.
> >
> > Server environment:
> >
> > * EC2 instance (cc2.8xlarge) (60 GB, 10 GB network, 16
> > vCPUs)
> >
> > * Server 2008 R2
> >
> > * Tomcat 7.0.48 (trunk)
> >
> > * Java 1.7.0_45
> 
> Look at your memory usage. My guess based on my simple test results is that
> the JVM for both Tomcat and the client isn't grabbing as much memory as it
> really needs. If that is the problem then -Xms20G -Xmx30G should do the trick.
> 
> Keep in mind that Tomcat is allocating at several 8k buffers for each
> connection (client and server - I'd need to check the code to be sure how many
> buffers are allocated per connection) so you are going to need a fair amount 
> of
> RAM. The TCP buffers will need quite a lot of space too but that should be
> outside of the Java Object Heap.

In monitoring the memory, it's not nearing the max available we configured for 
the JVM, but perhaps there's something going on GC wise.  I don't have GC 
logging enabled and probably should.  I haven't done much with that aspect of 
tuning yet.

>From a Tomcat connector standpoint, should we consider increasing any of the 
>acceptThreadCount and acceptCount values - given it's such a large machine?

> 

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


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

RE: attempting to achieve 100K concurrent websocket connections on Tomcat 7.0.48 NIO

[Bob DeRemer]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, November 01, 2013 6:11 PM
> To: Tomcat Users List
> Subject: Re: attempting to achieve 100K concurrent websocket connections on
> Tomcat 7.0.48 NIO
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Bob,
> 
> Just a quick note: with NIO, you should not need 100k threads to serve 100k
> connections. Can a single process even request 100k threads from the OS under
> your current environment?
> 

Hi Chris,

As for a single client requesting 100K, no.  There's a limit to the number of 
ephemeral ports outbound, but 40 - 50K is definitely doable per machine.

We'll try setting maxThreads = -1 (like Mark mentioned), just to see how it 
works.  With regard to machines, the client and server are both BIG EC2 
instances with 16 vCPUs and 60 GB RAM.We were able to get 2 client 
machines, each running 1 java process simulating 40K websocket clients, 
connected to 1 Tomcat server instance - so 80K concurrent connections.  It just 
seems that if we hit it too hard all at once, there are problems and we can't 
quite determine what's at the root of it.

Thx,
Bob

> - -chris
> 
> On 11/1/13, 6:00 PM, Bob DeRemer wrote:
> > QUESTION: I'm looking for some advice on what Tomcat NIO connector
> > settings to use to support 100K concurrent websocket connections.
> > Hopefully I  can reach this goal through a combination of Tomcat NIO
> > Connector settings, and Server 2008 R2 configuration [if needed].
> >
> > BACKGROUND: We're scale testing our websocket application and looking
> > to see how many concurrent websocket connections we can get on a
> > single Tomcat instance - with the goal being 100K.  I've provided the
> > test landscape details at the bottom - all VERY BIG
> > EC2 instances over 10 GB network, so memory, CPU and network do not
> > appear to be the problem when monitoring.
> >
> > PROBLEM: The problem we are running into is that we can't seem to
> > establish even 50K connections into Tomcat.  At some point, we start
> > getting connect failures, similar to the following:
> >
> > Couldn't connect java.io.EOFException: null at
> >
> org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWe
> b
> > SocketContainer.java:570) ~[tomcat7-websocket.jar:7.0.48-dev] at
> >
> org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWe
> b
> > SocketContainer.java:317) ~[tomcat7-websocket.jar:7.0.48-dev] Wrapped
> > by:
> > javax.websocket.DeploymentException: The HTTP request to initiate the
> > WebSocket connection failed at
> >
> org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWe
> b
> > SocketContainer.java:344)
> > ~[tomcat7-websocket.jar:7.0.48-dev]
> >
> > I'm hoping that someone may be able to advise what changes we might
> > make to the following Tomcat NIO connector setting that will allow
> > upwards of 100K websocket connections:
> >
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > connectionTimeout="2" maxConnections="10"
> > maxThreads="10" redirectPort="8443" />
> >
> >
> > TEST LANDSCAPE:
> >
> > The test landscape is all Windows Server 2008 R2 boxes running in
> > EC2 and the Test Client environment:
> >
> > Our test client is a multi-threaded java client that makes use of the
> > JSR356 ClientEndpoint functionality.  We're creating 40K+ websocket
> > connections from a single test client machine.  The test client is
> > Server 2008 R2 and we have configured it to allow 50K ephemeral ports,
> > so we should be able to establish 40K+ outbound websocket connections.
> >
> > Server environment:
> >
> > * EC2 instance (cc2.8xlarge) (60 GB, 10 GB network, 16
> > vCPUs)
> >
> > * Server 2008 R2
> >
> > * Tomcat 7.0.48 (trunk)
> >
> > * Java 1.7.0_45
> >
> >
> > Thanks, Bob
> >
> > http://www.thingworx.com<http://www.thingworx.com/> Skype:
> > bob.deremer.thingworx O: 610.594.6200 x812 M: 717.881.3986
> >
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJSdCb1AAoJEBzwKT+lPKRYZYEP/0kLnRF3f8BIw9KhIbf+uv1d
> Gr5MyMkx3HBpgEHw36hUfoiEEKE06mHfff3DRP9troCs6h8VovS/4jk1ti6NU1Kh
> FPVTF0FHiNC1kRtyvvw2avCJMSHYSnAUArDKkwO6wydTVsyTmGOPlL7u99A

attempting to achieve 100K concurrent websocket connections on Tomcat 7.0.48 NIO

[Bob DeRemer]

QUESTION:
I'm looking for some advice on what Tomcat NIO connector settings to use to 
support 100K concurrent websocket connections.  Hopefully I  can reach this 
goal through a combination of Tomcat NIO Connector settings, and Server 2008 R2 
configuration [if needed].

BACKGROUND:
We're scale testing our websocket application and looking to see how many 
concurrent websocket connections we can get on a single Tomcat instance - with 
the goal being 100K.  I've provided the test landscape details at the bottom - 
all VERY BIG EC2 instances over 10 GB network, so memory, CPU and network do 
not appear to be the problem when monitoring.

PROBLEM:
The problem we are running into is that we can't seem to establish even 50K 
connections into Tomcat.  At some point, we start getting connect failures, 
similar to the following:

Couldn't connect java.io.EOFException: null
at 
org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:570)
 ~[tomcat7-websocket.jar:7.0.48-dev]
at 
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:317)
 ~[tomcat7-websocket.jar:7.0.48-dev]
Wrapped by: javax.websocket.DeploymentException: The HTTP request to initiate 
the WebSocket connection failed
at 
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:344)
 ~[tomcat7-websocket.jar:7.0.48-dev]

I'm hoping that someone may be able to advise what changes we might make to the 
following Tomcat NIO connector setting that will allow upwards of 100K 
websocket connections:




TEST LANDSCAPE:

The test landscape is all Windows Server 2008 R2 boxes running in EC2 and the
Test Client environment:

Our test client is a multi-threaded java client that makes use of the JSR356 
ClientEndpoint functionality.  We're creating 40K+ websocket connections from a 
single test client machine.  The test client is Server 2008 R2 and we have 
configured it to allow 50K ephemeral ports, so we should be able to establish 
40K+ outbound websocket connections.

Server environment:

* EC2 instance (cc2.8xlarge) (60 GB, 10 GB network, 16 vCPUs)

* Server 2008 R2

* Tomcat 7.0.48 (trunk)

* Java 1.7.0_45


Thanks,
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

Possible serious bug in Tomcat 7's websocket UpgradeUtil when handling concurrent connections that use a custom ServerEndpointConfig.Configurator

[Bob DeRemer]

It appears that there is 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 handshake/onOpen process?


Thanks,
Bob

http://www.thingworx.com
Skype: bob.deremer.thingworx

are there any websocket-specific tomcat 7 connector settings?

[Bob DeRemer]

Hi Community,

As we start load testing our jsr-356 applications, I'd like to find out if 
there are any websocket-specific connector settings we should be aware of for 
tuning the underlying websocket connection processing.  Since this is a tcp 
socket at the end of the day, I'm assuming all the socket.* options still apply 
if needed.  We are currently testing with the latest trunk build of 7.0 
(48-dev) using the NIO connector only - no APR.

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: is the Tomcat-7 WsRemoteEndpointImplBase send methods threadsafe, or should we be synchronizing until the Future<>.get() returns?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, October 22, 2013 3:32 AM
> To: Tomcat Users List
> Subject: Re: is the Tomcat-7 WsRemoteEndpointImplBase send methods
> threadsafe, or should we be synchronizing until the Future<>.get() returns?
> 
> On 22/10/2013 00:28, Bob DeRemer wrote:
> > I'm trying to understand how Tomcat's outbound message processing
> > works with respect to making multiple (concurrent) calls against a
> > single RemoteEndpoint.Async using sendText/sendObject.  Based on the
> > ExecutionExceptions we got (see below), it seems that we should
> > probably synchronize sends until the Future<>.get() returns, but I
> > want to check with the community to be sure.  I tried searching the
> > javadocs of RemoteEndpoint.Async and associated interfaces, but could
> > not find anything describing the threadsafe nature (existing or not).
> > It appears that the spec lets the implementation determine how to
> > handle stuff under the covers.  This is fine, but we just need to
> > understand what that means to multi-threaded code that wants to send
> > messages.
> 
> There was some discussion [1] in the EG on this point and the conclusion was
> that the previous message had to complete before the next message was sent.
> If you batching is used (which Tomcat supports) the semantics for complete
> change but the previous message still has to complete before the next is sent.
> 
> I've looked through the specification and I don't see this made clear 
> anywhere.
> My experience of the J2EE EG's is that in cases like these following the
> intention of the EG based on the mailing list archive is the way to go.
> 
> > Looking at the Tomcat code, it looks like WsRemoteEndpointImplBase
> > uses a static SendHandler (i.e. TextMessageSendHandler).
> 
> That is a static definition of a class, not a static instance. A new instance 
> is
> created for each message.
> 
> > I noticed a
> > little further down in the stack the logic does synchronize around a
> > messagePartQueue, but this seems to be for handling parts of a single
> > message.
> 
> Correct. That is to ensure correct state management when different threads
> are sending different parts of the message.
> 
> > Otherwise, it looks like it doesn't expect another message to be sent
> > until it's finished writing out.
> 
> Correct. It should throw an exception if you try.
> 
> > ExecutionException: In some recent testing of our client/server
> > Endpoint(s) (using a locally built instance of Tomcat 7.0.48), we got
> > ExecutionExceptions when sending messages concurrently without any
> > delay.  The errors started with a few Null Ptr(s), then were all
> > wsRemoteEndpoint.inProgress (Message will not be sent because the
> > WebSocket session is currently sending another message)
> >
> > Is my understanding correct, or am I missing something?  Thanks in
> > advance for any clarification.
> 
> HTH,
> 
> Mark

Great - thanks for the plumbing explanation!
bob

> 
> [1]
> https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-
> 02/message/1
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: is the Tomcat-7 WsRemoteEndpointImplBase send methods threadsafe, or should we be synchronizing until the Future<>.get() returns?

[Bob DeRemer]

> -Original Message-
> From: Niki Dokovski [mailto:nick...@gmail.com]
> Sent: Tuesday, October 22, 2013 1:11 AM
> To: Tomcat Users List
> Subject: Re: is the Tomcat-7 WsRemoteEndpointImplBase send methods
> threadsafe, or should we be synchronizing until the Future<>.get() returns?
> 
> On Tue, Oct 22, 2013 at 3:29 AM, David Bullock <
> david.bull...@machaira.com.au> wrote:
> 
> > Hi Bob,
> >
> > > I tried searching the javadocs of RemoteEndpoint.Async and
> > > associated
> > interfaces, but could not find anything describing the threadsafe
> > nature (existing or not).  It appears that the spec lets the
> > implementation determine how to handle stuff under the covers.  This
> > is fine, but we just need to understand what that means to
> > multi-threaded code that wants to send messages.
> >
> 
> JSR 356 Specification Section 5.1 Threading Consideration discusses the topic.
> In particular;
> [WSC-5.1-2] - "the implementation must not invoke an endpoint instance with
> more than one thread per peer at a time."
> [WSC-5.1-4] - "a websocket endpoint instance is never called by more than one
> container thread at a time per peer."
> 
> cheers
> 

Thank you, Niki, for the spec clarification
bob

> 
> >
> > I'd have thought that where an interface doesn't declare that it is
> > threadsafe, one cannot assume that it will be.  Further, if a
> > RemoteEndpoint represents 'the peer of a web socket conversation',
> > then a RemoteEndpoint, like a conversation, can surely support only a
> > single 'conversation state'?
> >
> > IMHO, the correct choice is for each thread to have its own
> > RemoteEndpoint.  If the protocol being used happens to multiplex
> > multiple conversations to/from different endpoints over the same
> > TCP/UDP socket (for example), then the plumbing will do the
> > appropriate synchronization at that point - there would be no
> > advantage (and possibly some big disadvantages) for you to do your own
> > synchronization.  Critically, a RemoteEndpoint does not necessarily
> > represent a 'heavyweight' object like a Socket, and you should not be
> > at pains to manage your own pool of them, nor necessarily (unless it
> > made sense for application logic) to have a queue of messages which is
> > dispatched from a single thread.
> >
> > However, I do think that many JSR's which ought to know better are
> > very lame about thread-safety guarantees for application authors, and
> > that more needs to be said in API documentation about patterns for
> > concurrent usage.  I encourage you to lobby your particular JSR of use
> > to include this information in future releases of the specification.
> > I did my bit recently at https://java.net/jira/browse/SERVLET_SPEC-81
> >
> > cheers,
> > David Bullock
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

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

is the Tomcat-7 WsRemoteEndpointImplBase send methods threadsafe, or should we be synchronizing until the Future<>.get() returns?

[Bob DeRemer]

I'm trying to understand how Tomcat's outbound message processing works with 
respect to making multiple (concurrent) calls against a single 
RemoteEndpoint.Async using sendText/sendObject.  Based on the 
ExecutionExceptions we got (see below), it seems that we should probably 
synchronize sends until the Future<>.get() returns, but I want to check with 
the community to be sure.  I tried searching the javadocs of 
RemoteEndpoint.Async and associated interfaces, but could not find anything 
describing the threadsafe nature (existing or not).  It appears that the spec 
lets the implementation determine how to handle stuff under the covers.  This 
is fine, but we just need to understand what that means to multi-threaded code 
that wants to send messages.

Looking at the Tomcat code, it looks like WsRemoteEndpointImplBase uses a 
static SendHandler (i.e. TextMessageSendHandler).  I noticed a little further 
down in the stack the logic does synchronize around a messagePartQueue, but 
this seems to be for handling parts of a single message.  Otherwise, it looks 
like it doesn't expect another message to be sent until it's finished writing 
out.

ExecutionException:
In some recent testing of our client/server Endpoint(s) (using a locally built 
instance of Tomcat 7.0.48), we got ExecutionExceptions when sending messages 
concurrently without any delay.  The errors started with a few Null Ptr(s), 
then were all wsRemoteEndpoint.inProgress (Message will not be sent because the 
WebSocket session is currently sending another message)

Is my understanding correct, or am I missing something?  Thanks in advance for 
any clarification.


Thanks,

Bob DeRemer
http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer.thingworx

RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBase.onMessage

[Bob DeRemer]

> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Sunday, October 20, 2013 8:22 AM
> To: Tomcat Users List
> Subject: RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown
> when DecodeException is caught in
> PojoMessageHandlerWholeBase.onMessage
> 
> Morning Bob-
> 
> 
> 
> session should never be null..this is a bug
> 
> 
> 
> create an account here
> 
> https://issues.apache.org/bugzilla/createaccount.cgi
> 
> 
> and file the bug report
> 
> 

Bug report submitted
Thx, bob

> 
> Many thanks for discovering this bug and helping us to improve the product
> 
> 
> Martin
> __
> 
> 
> 
> 
> 
> 
> 
> From: bob.dere...@thingworx.com
> To: users@tomcat.apache.org
> Subject: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when
> DecodeException is caught in PojoMessageHandlerWholeBase.onMessage
> Date: Sat, 19 Oct 2013 12:46:05 +
> 
> 
> 
> 
> 
> 
> 
> 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
> 
> 
> http://www.thingworx.com
> Skype: bob.deremer.thingworx
> O: 610.594.6200 x812
> M: 717.881.3986
> 

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

RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBase.onMessage

[Bob DeRemer]

I have re-posted to DEV so please disregard

From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
Sent: Saturday, October 19, 2013 8:46 AM
To: Tomcat Users List
Subject: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when 
DecodeException is caught in PojoMessageHandlerWholeBase.onMessage

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

possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBase.onMessage

[Bob DeRemer]

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: any update on an anticipated release date for 7.0.43?

[Bob DeRemer]

From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
Sent: Friday, September 20, 2013 10:48 AM
To: Tomcat Users List
Subject: Re: any update on an anticipated release date for 7.0.43?


On Sep 20, 2013, at 9:18 AM, Bob DeRemer wrote:





-Original Message-
From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
Sent: Tuesday, September 17, 2013 12:28 PM
To: Tomcat Users List
Subject: RE: any update on an anticipated release date for 7.0.43?



-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, September 17, 2013 11:49 AM
To: Tomcat Users List
Subject: Re: any update on an anticipated release date for 7.0.43?

On 17/09/2013 15:53, Bob DeRemer wrote:
Has a decision (even tentative) been made on when 7.0.43 GA (w/ jsr
356)
will release?  Just curious if this will be before the end of September.

The native release this was blocked by has now happened. Running the
unit tests has identified a series of problems with WebSocket and the
APR/native connector on Windows. I think these are fixed but I need to
wait for the unit test runs to complete. Literally as I typed the last
sentence the Windows tests finished and they passed. Woot!

I'll be tagging 8.0.0-RC2 in the next few hours. I expect Violeta will
be tagging
7.0.43 either later today or early tomorrow.

Awesome - thx for the update!
-bob


Is it still looking good for a 7.0.43 release this week?   I noticed nothing 
has been tagged yet, so didn't know if there were some problems uncovered that 
need to be fixed.

7.0.43 was tagged about 6 hours before you sent this message :-):

http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_43/

There is also currently a vote happening on the developer mailing list as to 
its stability and whether to release:

http://tomcat.markmail.org/thread/yjx2p5n62k2mdcrt

The Tomcat team encourages people willing to test proposed Tomcat releases 
before they are published to join the developer mailing list, download the 
proposed release, test it out, and report back any issues that they believe 
should block the release, if any, in the form of a non-binding vote on the 
release.

Hope this helps,

Nick

That's great.   I had checked right before emailing, but turns out my browser 
cached the tags URL and 43 didn't show up.

I will definitely pull down/build it and let you know if we have any problems.

-bob

RE: any update on an anticipated release date for 7.0.43?

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Tuesday, September 17, 2013 12:28 PM
> To: Tomcat Users List
> Subject: RE: any update on an anticipated release date for 7.0.43?
> 
> 
> 
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Tuesday, September 17, 2013 11:49 AM
> > To: Tomcat Users List
> > Subject: Re: any update on an anticipated release date for 7.0.43?
> >
> > On 17/09/2013 15:53, Bob DeRemer wrote:
> > > Has a decision (even tentative) been made on when 7.0.43 GA (w/ jsr
> > > 356)
> > will release?  Just curious if this will be before the end of September.
> >
> > The native release this was blocked by has now happened. Running the
> > unit tests has identified a series of problems with WebSocket and the
> > APR/native connector on Windows. I think these are fixed but I need to
> > wait for the unit test runs to complete. Literally as I typed the last
> > sentence the Windows tests finished and they passed. Woot!
> >
> > I'll be tagging 8.0.0-RC2 in the next few hours. I expect Violeta will
> > be tagging
> > 7.0.43 either later today or early tomorrow.
> 
> Awesome - thx for the update!
> -bob
> 

Is it still looking good for a 7.0.43 release this week?   I noticed nothing 
has been tagged yet, so didn't know if there were some problems uncovered that 
need to be fixed.

thx

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


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

RE: any update on an anticipated release date for 7.0.43?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, September 17, 2013 11:49 AM
> To: Tomcat Users List
> Subject: Re: any update on an anticipated release date for 7.0.43?
> 
> On 17/09/2013 15:53, Bob DeRemer wrote:
> > Has a decision (even tentative) been made on when 7.0.43 GA (w/ jsr 356)
> will release?  Just curious if this will be before the end of September.
> 
> The native release this was blocked by has now happened. Running the unit
> tests has identified a series of problems with WebSocket and the APR/native
> connector on Windows. I think these are fixed but I need to wait for the unit
> test runs to complete. Literally as I typed the last sentence the Windows 
> tests
> finished and they passed. Woot!
> 
> I'll be tagging 8.0.0-RC2 in the next few hours. I expect Violeta will be 
> tagging
> 7.0.43 either later today or early tomorrow.

Awesome - thx for the update!
-bob

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


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

any update on an anticipated release date for 7.0.43?

[Bob DeRemer]

Has a decision (even tentative) been made on when 7.0.43 GA (w/ jsr 356) will 
release?  Just curious if this will be before the end of September.

Thanks,
Bob

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

RE: solution - RE: how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, September 10, 2013 12:07 PM
> To: Tomcat Users List
> Subject: Re: solution - RE: how to access HTTP response from jsr-356
> ServerEndpointConfig.Configurator.modifyHandshake?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Bob,
> 
> On 9/10/13 10:35 AM, Bob DeRemer wrote:
> > It appears I can call addFilter dynamically when my webapp starts up
> > and front-end the websocket endpoint with a Filter - processing the
> > initial HTTP request completely before any websocket communication is
> > involved
> 
> This was kind of what I was expecting to work.
> 
> But why do you have to add the Filter programmatically? Is this a component
> that you just want to bolt-onto an existing webapp and you don't want to mess
> with web.xml and/or web-fragments?
> 

It's actually a new application, but I wanted to add this programmatically 
because we're running off of our own configuration that will enable/disable 
certain functionality (i.e. endpoints/servlets/other components) based on that 
configuration.

So, a combination of our own requirements plus not wanting to work with 
web.xml/web-fragments.

> > Thanks for causing me to pull up from the weeds and look at this from
> > another angle!
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJSL0OZAAoJEBzwKT+lPKRYM7UP/2zdUaDr6LHE3onxUnRZ5jM
> /
> DptjeReE7nuLyqxINUlEF828XEfpZVlBS325Xfd8E13mB7bUg+aNGK2jjIsyhfjr
> B+tUBp0Ur52Dg5PDGPV6Qt4Obi8eg3766TQxleZU6ui3dWdLz5PdMeeSb+ZORG
> yN
> OvTuIsfVSsXw5C4Oi9CnqNo66xkMEwJFsKNs/0LalO3jGLlar/A6v2FpR+RTVwxw
> FZU2she8xCnq/PKkjHHBn5W3zxTEH9bwGRIDItk7GoS7AnloM+yiZLADftyfq1Hl
> k0gIGYxeS36QJ919puoHxybx2zfWY8GAVq+ePfPPkKr2OyQGXAdJ9jpQ44eIkoc6
> q3irwkjl/hi20EV34PqE5BZGZx16FIA7DtdgXNcZYg3ExJOndqPNhdoAlwg0pkge
> 22OJ7aVwXUUPppX0OUxl59KGW20+SPJnKTizsocT15dqac8VQR5OMcIrWLVHnc
> wH
> qj27qA8QeIcapbeC+Jhw4yIpTGeKCPKq3hRFhWuaZq3rUuDjJZN5d+b8rXeoeLb/
> q95i9JlocLpF6RwuFgzEios7sARfypAIcEfophti9NjtPT+8AL2ToCBMSfFL4ba7
> EBg27R/MrCvWvQ3uyVnc/+jX93ckAwyzblc1BxoElPJ4WzLxlVtUZspiyrByq8MI
> Qd2ne9627CNtjBYxej0J
> =mZw5
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: can a Filter be used to pre-process calls to a websocket endpoint?

[Bob DeRemer]

> From: Bob DeRemer [mailto:bob.dere...@thingworx.com] 
> Sent: Tuesday, September 10, 2013 10:08 AM
> To: Tomcat Users List
> Subject: can a Filter be used to pre-process calls to a websocket endpoint?

> Is it possible to programmatically add a Servlet Filter to Tomcat during the 
> ContextInitialized call so that it filters requests going to a websocket 
> endpoint?  

My apologies for posting before trying.  I was able to do this using 
ServletContext.addFilter and the FilterRegistration.Dynamic functionality.  As 
I suspected, by adding a mapping for the respective URLs, the request is 
filtered - regardless of whether it's going to a Servlet or WebSocket Endpoint.

> Thanks,

> Bob DeRemer
> Senior Director, Architecture and Development


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

RE: solution - RE: how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Tuesday, September 10, 2013 8:56 AM
> To: Tomcat Users List
> Subject: RE: solution - RE: how to access HTTP response from jsr-356
> ServerEndpointConfig.Configurator.modifyHandshake?
> 
> 
> 
> > -Original Message-
> > From: André Warnier [mailto:a...@ice-sa.com]
> > Sent: Tuesday, September 10, 2013 6:12 AM
> > To: Tomcat Users List
> > Subject: Re: solution - RE: how to access HTTP response from jsr-356
> > ServerEndpointConfig.Configurator.modifyHandshake?
> >
> > Bob DeRemer wrote:
> > >
> > >> -Original Message-
> > >> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> > >> Sent: Monday, September 09, 2013 1:30 PM
> > >> To: Tomcat Users List
> > >> Subject: RE: how to access HTTP response from jsr-356
> > >> ServerEndpointConfig.Configurator.modifyHandshake?
> > >>
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Niki Dokovski [mailto:nick...@gmail.com]
> > >>> Sent: Monday, September 09, 2013 1:11 PM
> > >>> To: Tomcat Users List
> > >>> Subject: Re: how to access HTTP response from jsr-356
> > >>> ServerEndpointConfig.Configurator.modifyHandshake?
> > >>>
> > >>> On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer
> > >>> wrote:
> > >>>
> > >>>>  Thanks for the direction on using the respective Client/Server
> > >>>> EndpointConfig.Configurator plumbing to do a pre-connection AUTH.
> > >>>> Unfortunately, I'm stuck on the server side when trying to
> > >>>> actually modify the HTTP response result code from within the
> Configurator.
> > >>>> It doesn't appear that the HandshakeResponse [or anything else
> > >>>> that I could see] provides access to modify the actual HTTP
> > >>>> response - setting it to
> > >>> 403 if
> > >>>> the AUTH fails.In fact, from looking at the UpgradeUtil.doUpgrade, 
> > >>>> it
> > >>>> seems that the decision to upgrade has already been made by the
> > >>>> time the modifyHandshake override gets called.
> > >>>>
> > >>> Yes the decision is'already made at that point. In this version of
> > >>> the spec and current implementation, the only place to actully
> > >>> provide different status code (aka 403) is when checkOrigin returns 
> > >>> false.
> > >>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerE
> > >>> nd
> > >>> po
> > >>> intC
> > >>> onfig.Configurator.html#checkOrigin(java.lang.String)
> > >>>
> > >>> I don't know wether this works in your case, but for sure the next
> > >>> spec revision could try to provide more application control in
> > >> "modifyHandshake"
> > >> checkOrigin would work if there was some way to gain access to the
> > >> client supplied headers.  Is there any way for my checkOrigin
> > >> method to get access to the calling request and associated HTTP
> > >> headers?  If not, then I'm not sure how to perform a pre-connected
> > >> AUTH check based
> > on the current implementation.
> > >>
> > >> if there are any other suggestions, please LMK; meanwhile, I'll
> > >> keep digging to see if there's another solution.
> > >>
> > >> Thx,bob
> > >>
> > >
> > > After looking at the options available and going through the
> > > websocket
> > protocol specification again, I've found a better solution for
> > authenticating using a JSR-356 implementation than the original
> > concept of using ServerEndpointConfig.Configurator.modifyHandshake.
> > The new approach still uses custom Client and Server
> > EndpointConfig/Configurator instances to pass security information
> > during the handshake, but instead of rejecting the handshake, it's
> > cleaner to grab the security information in the OnOpen (from the
> > ServerEndpointConfig) of the actual endpoint.  At this point, simply
> > perform whatever AAA you wish - calling close with an appropriate
> CloseReason if AAA fails.
> > >
> > > With regard to DOS and opening websocket connections:
> > >
> > &g

can a Filter be used to pre-process calls to a websocket endpoint?

[Bob DeRemer]

Is it possible to programmatically add a Servlet Filter to Tomcat during the 
ContextInitialized call so that it filters requests going to a websocket 
endpoint?


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: solution - RE: how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Tuesday, September 10, 2013 6:12 AM
> To: Tomcat Users List
> Subject: Re: solution - RE: how to access HTTP response from jsr-356
> ServerEndpointConfig.Configurator.modifyHandshake?
> 
> Bob DeRemer wrote:
> >
> >> -----Original Message-
> >> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> >> Sent: Monday, September 09, 2013 1:30 PM
> >> To: Tomcat Users List
> >> Subject: RE: how to access HTTP response from jsr-356
> >> ServerEndpointConfig.Configurator.modifyHandshake?
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Niki Dokovski [mailto:nick...@gmail.com]
> >>> Sent: Monday, September 09, 2013 1:11 PM
> >>> To: Tomcat Users List
> >>> Subject: Re: how to access HTTP response from jsr-356
> >>> ServerEndpointConfig.Configurator.modifyHandshake?
> >>>
> >>> On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer
> >>> wrote:
> >>>
> >>>>  Thanks for the direction on using the respective Client/Server
> >>>> EndpointConfig.Configurator plumbing to do a pre-connection AUTH.
> >>>> Unfortunately, I'm stuck on the server side when trying to actually
> >>>> modify the HTTP response result code from within the Configurator.
> >>>> It doesn't appear that the HandshakeResponse [or anything else that
> >>>> I could see] provides access to modify the actual HTTP response -
> >>>> setting it to
> >>> 403 if
> >>>> the AUTH fails.In fact, from looking at the UpgradeUtil.doUpgrade, it
> >>>> seems that the decision to upgrade has already been made by the
> >>>> time the modifyHandshake override gets called.
> >>>>
> >>> Yes the decision is'already made at that point. In this version of
> >>> the spec and current implementation, the only place to actully
> >>> provide different status code (aka 403) is when checkOrigin returns false.
> >>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEnd
> >>> po
> >>> intC
> >>> onfig.Configurator.html#checkOrigin(java.lang.String)
> >>>
> >>> I don't know wether this works in your case, but for sure the next
> >>> spec revision could try to provide more application control in
> >> "modifyHandshake"
> >> checkOrigin would work if there was some way to gain access to the
> >> client supplied headers.  Is there any way for my checkOrigin method
> >> to get access to the calling request and associated HTTP headers?  If
> >> not, then I'm not sure how to perform a pre-connected AUTH check based
> on the current implementation.
> >>
> >> if there are any other suggestions, please LMK; meanwhile, I'll keep
> >> digging to see if there's another solution.
> >>
> >> Thx,bob
> >>
> >
> > After looking at the options available and going through the websocket
> protocol specification again, I've found a better solution for authenticating
> using a JSR-356 implementation than the original concept of using
> ServerEndpointConfig.Configurator.modifyHandshake.  The new approach still
> uses custom Client and Server EndpointConfig/Configurator instances to pass
> security information during the handshake, but instead of rejecting the
> handshake, it's cleaner to grab the security information in the OnOpen (from
> the ServerEndpointConfig) of the actual endpoint.  At this point, simply 
> perform
> whatever AAA you wish - calling close with an appropriate CloseReason if AAA
> fails.
> >
> > With regard to DOS and opening websocket connections:
> >
> > The websocket protocol already prohibits multiple clients from being in the
> connecting/handshake phase at once, which already helps reduce the DOS
> surface area.  In addition, the client and/or server side implementations can
> add additional logic to prohibit the number of concurrent connections from the
> same client endpoint based on configuration.
> >
> > And, yes, once I get it done and tested, I'll write this up.
> >
> 
> Hi.
> I have been watching this a bit from the outside, and I am neither a Java nor 
> a
> Tomcat nor a websocket expert.
> But I am wondering a bit if we are not here missing the forest for the trees, 
> in
> the following sense :
> If I understand correctly the issue at hand, it would be about
> 

solution - RE: how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Monday, September 09, 2013 1:30 PM
> To: Tomcat Users List
> Subject: RE: how to access HTTP response from jsr-356
> ServerEndpointConfig.Configurator.modifyHandshake?
> 
> 
> 
> > -Original Message-
> > From: Niki Dokovski [mailto:nick...@gmail.com]
> > Sent: Monday, September 09, 2013 1:11 PM
> > To: Tomcat Users List
> > Subject: Re: how to access HTTP response from jsr-356
> > ServerEndpointConfig.Configurator.modifyHandshake?
> >
> > On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer
> > wrote:
> >
> > >  Thanks for the direction on using the respective Client/Server
> > > EndpointConfig.Configurator plumbing to do a pre-connection AUTH.
> > > Unfortunately, I'm stuck on the server side when trying to actually
> > > modify the HTTP response result code from within the Configurator.
> > > It doesn't appear that the HandshakeResponse [or anything else that
> > > I could see] provides access to modify the actual HTTP response -
> > > setting it to
> > 403 if
> > > the AUTH fails.In fact, from looking at the UpgradeUtil.doUpgrade, it
> > > seems that the decision to upgrade has already been made by the time
> > > the modifyHandshake override gets called.
> > >
> > Yes the decision is'already made at that point. In this version of the
> > spec and current implementation, the only place to actully provide
> > different status code (aka 403) is when checkOrigin returns false.
> > http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo
> > intC
> > onfig.Configurator.html#checkOrigin(java.lang.String)
> >
> > I don't know wether this works in your case, but for sure the next
> > spec revision could try to provide more application control in
> "modifyHandshake"
> >
> 
> checkOrigin would work if there was some way to gain access to the client
> supplied headers.  Is there any way for my checkOrigin method to get access to
> the calling request and associated HTTP headers?  If not, then I'm not sure 
> how
> to perform a pre-connected AUTH check based on the current implementation.
> 
> if there are any other suggestions, please LMK; meanwhile, I'll keep digging 
> to
> see if there's another solution.
> 
> Thx,bob
> 

After looking at the options available and going through the websocket protocol 
specification again, I've found a better solution for authenticating using a 
JSR-356 implementation than the original concept of using 
ServerEndpointConfig.Configurator.modifyHandshake.  The new approach still uses 
custom Client and Server EndpointConfig/Configurator instances to pass security 
information during the handshake, but instead of rejecting the handshake, it's 
cleaner to grab the security information in the OnOpen (from the 
ServerEndpointConfig) of the actual endpoint.  At this point, simply perform 
whatever AAA you wish - calling close with an appropriate CloseReason if AAA 
fails.  

With regard to DOS and opening websocket connections:

The websocket protocol already prohibits multiple clients from being in the 
connecting/handshake phase at once, which already helps reduce the DOS surface 
area.  In addition, the client and/or server side implementations can add 
additional logic to prohibit the number of concurrent connections from the same 
client endpoint based on configuration.

And, yes, once I get it done and tested, I'll write this up.

-bob

> > cheers
> > Niki
> >
> >
> >
> > 
> > >
> > > ** **
> > >
> > > If I'm missing anything, please let me know.
> > >
> > > ** **
> > >
> > > Thanks,
> > >
> > > ** **
> > >
> > > *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
> > >
> > > ** **
> > >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

> -Original Message-
> From: Niki Dokovski [mailto:nick...@gmail.com]
> Sent: Monday, September 09, 2013 1:11 PM
> To: Tomcat Users List
> Subject: Re: how to access HTTP response from jsr-356
> ServerEndpointConfig.Configurator.modifyHandshake?
> 
> On Mon, Sep 9, 2013 at 5:26 PM, Bob DeRemer
> wrote:
> 
> >  Thanks for the direction on using the respective Client/Server
> > EndpointConfig.Configurator plumbing to do a pre-connection AUTH.
> > Unfortunately, I'm stuck on the server side when trying to actually
> > modify the HTTP response result code from within the Configurator.  It
> > doesn't appear that the HandshakeResponse [or anything else that I
> > could see] provides access to modify the actual HTTP response - setting it 
> > to
> 403 if
> > the AUTH fails.In fact, from looking at the UpgradeUtil.doUpgrade, it
> > seems that the decision to upgrade has already been made by the time
> > the modifyHandshake override gets called.
> >
> Yes the decision is'already made at that point. In this version of the spec 
> and
> current implementation, the only place to actully provide different status 
> code
> (aka 403) is when checkOrigin returns false.
> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointC
> onfig.Configurator.html#checkOrigin(java.lang.String)
> 
> I don't know wether this works in your case, but for sure the next spec 
> revision
> could try to provide more application control in "modifyHandshake"
> 

checkOrigin would work if there was some way to gain access to the client 
supplied headers.  Is there any way for my checkOrigin method to get access to 
the calling request and associated HTTP headers?  If not, then I'm not sure how 
to perform a pre-connected AUTH check based on the current implementation.

if there are any other suggestions, please LMK; meanwhile, I'll keep digging to 
see if there's another solution.

Thx,bob

> cheers
> Niki
> 
> 
> 
> 
> >
> > ** **
> >
> > If I'm missing anything, please let me know.
> >
> > ** **
> >
> > Thanks,
> >
> > ** **
> >
> > *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
> >
> > ** **
> >

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

how to access HTTP response from jsr-356 ServerEndpointConfig.Configurator.modifyHandshake?

[Bob DeRemer]

Thanks for the direction on using the respective Client/Server 
EndpointConfig.Configurator plumbing to do a pre-connection AUTH.  
Unfortunately, I'm stuck on the server side when trying to actually modify the 
HTTP response result code from within the Configurator.  It doesn't appear that 
the HandshakeResponse [or anything else that I could see] provides access to 
modify the actual HTTP response - setting it to 403 if the AUTH fails.In 
fact, from looking at the UpgradeUtil.doUpgrade, it seems that the decision to 
upgrade has already been made by the time the modifyHandshake override gets 
called.

If I'm missing anything, please let me know.

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: (7.0.40) Seeing deadlock followed by maxThread usage using a Async Servlet AsyncContext.dispatch with BIO

[Bob DeRemer]

> -Original Message-
> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Sent: Friday, September 06, 2013 9:45 AM
> To: Tomcat Users List
> Subject: RE: (7.0.40) Seeing deadlock followed by maxThread usage using a
> Async Servlet AsyncContext.dispatch with BIO
> 
> 
> 
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Friday, September 06, 2013 9:25 AM
> > To: users@tomcat.apache.org
> > Subject: Re: (7.0.40) Seeing deadlock followed by maxThread usage
> > using a Async Servlet AsyncContext.dispatch with BIO
> >
> > On 06/09/2013 13:28, Daniel Mikusa wrote:
> > > On Sep 5, 2013, at 3:30 PM, Bob DeRemer 
> > wrote:
> > >
> > >> I'm trying to determine if there are any known issues using an
> > >> Async servlet
> > with the default BIO connector in Tomcat 7.0.40 on windows server 2008.
> > >>
> > >> PROBLEM:
> > >> We have a situation where we're occasionally getting a deadlock
> > >> (according
> > to Java Melody).  When this happens, it's just a matter of time until
> > all the threads in the connector's internal pool are exhausted because
> > browser-based clients continue to make calls on this async servlet -
> > effectively polling for work.
> > >>
> > >> QUESTION:
> > >> I'm in the process of going through the stacks and code, but I'm
> > >> not well
> > versed in the async servlet code (which is mostly from the Vysper
> > project), so I'm trying to figure out if the underlying
> > AsyncContext.dispatch usage is a problem [at least when used with BIO].
> > >>
> > >> Given the 3 stacks below, I'd greatly appreciate it if someone who
> > understands the Async servlet plumbing might be able to take a quick
> > look and see if anything stands out that could be the cause.  If you
> > need any additional information, please let me know.
> > >>
> > >> Thanks,
> > >> Bob
> > >
> > > Is there any chance you could get a full thread dump while the
> > > problem is
> > occurring?  The thread dump below doesn't have any information about
> > what locks are being held by the blocked threads.  I think that might
> > help to see why each thread is blocking.
> >
> > +1.
> >
> > What I would say is that there is no async code involved in the
> > http-bio-192.168.230.133-443-exec-1329 thread which makes me suspect
> > the vysper code.
> >
> > The only locks I'd expect Tomcat to be holding are on the socket to
> > ensure that only one thread processes a connection at a time and I'm
> > pretty such there is no opportunity for deadlock there.
> >
> > A closer look at BoshBackedSessionContext is probably in order.
> >
> > Mark
> >
> 
> Thanks for the suggestions!  I have already found the problem, which (as you
> suspected), is in the BoshBackedSessionContext.  There is a potential deadlock
> between the BoshBackedSessionContext and the underlying JIoEndpoint.  It's
> happening because the Vypser code has 2 methods using "synchronized":
> 
>  - 1 thd is doing an AsyncContext.dispatch from a synchronized method of
> BoshBackedSessionContext which hangs waiting for the JIoEndpoint
> synchronized socket wrapper in processSocketAsync
> - the other thd is the async timeout in JIoEndpoint firing back into the
> BoshBackedSessionContext; he acquired the socket wrapper sync and is
> attempting to a different synchronized method on the same
> BoshBackedSessionContext
> 
> So, I'm going to remove the synchronized usage from the
> BoshBackedSessionContext and replace with a Lock/Condition using a tryLock
> with timeout and 1 retry.  I've used this approach before and it's typically 
> a lot
> more performant and provides better control over situations like this.
> 
> Thx, bob

CORRECTION: only a Lock is needed for this fix, no Condition; so accustomed to 
using them together

> 
> > >
> > > Dan
> > >
> > >
> > >>
> > >> DEADLOCKED STACK INFORMATION
> > >>
> > >> Warning, the following threads are deadlocked :
> > >> http-bio-192.168.230.133-443-exec-1329,
> > >> http-bio-192.168.230.133-443-exec-685,
> > >> http-bio-192.168.230.133-443-exec-687
> > >>
> > >> "http-bio-192.168.230.133-443-exec-685" daemon prio=5 BLOCKED
> > >>
> > org.apache.tomcat.util.net.JIoEndpoint.p

RE: (7.0.40) Seeing deadlock followed by maxThread usage using a Async Servlet AsyncContext.dispatch with BIO

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, September 06, 2013 9:25 AM
> To: users@tomcat.apache.org
> Subject: Re: (7.0.40) Seeing deadlock followed by maxThread usage using a
> Async Servlet AsyncContext.dispatch with BIO
> 
> On 06/09/2013 13:28, Daniel Mikusa wrote:
> > On Sep 5, 2013, at 3:30 PM, Bob DeRemer 
> wrote:
> >
> >> I'm trying to determine if there are any known issues using an Async 
> >> servlet
> with the default BIO connector in Tomcat 7.0.40 on windows server 2008.
> >>
> >> PROBLEM:
> >> We have a situation where we're occasionally getting a deadlock (according
> to Java Melody).  When this happens, it's just a matter of time until all the
> threads in the connector's internal pool are exhausted because browser-based
> clients continue to make calls on this async servlet - effectively polling for
> work.
> >>
> >> QUESTION:
> >> I'm in the process of going through the stacks and code, but I'm not well
> versed in the async servlet code (which is mostly from the Vysper project), so
> I'm trying to figure out if the underlying AsyncContext.dispatch usage is a
> problem [at least when used with BIO].
> >>
> >> Given the 3 stacks below, I'd greatly appreciate it if someone who
> understands the Async servlet plumbing might be able to take a quick look and
> see if anything stands out that could be the cause.  If you need any 
> additional
> information, please let me know.
> >>
> >> Thanks,
> >> Bob
> >
> > Is there any chance you could get a full thread dump while the problem is
> occurring?  The thread dump below doesn't have any information about what
> locks are being held by the blocked threads.  I think that might help to see 
> why
> each thread is blocking.
> 
> +1.
> 
> What I would say is that there is no async code involved in the
> http-bio-192.168.230.133-443-exec-1329 thread which makes me suspect the
> vysper code.
> 
> The only locks I'd expect Tomcat to be holding are on the socket to ensure 
> that
> only one thread processes a connection at a time and I'm pretty such there is
> no opportunity for deadlock there.
> 
> A closer look at BoshBackedSessionContext is probably in order.
> 
> Mark
> 

Thanks for the suggestions!  I have already found the problem, which (as you 
suspected), is in the BoshBackedSessionContext.  There is a potential deadlock 
between the BoshBackedSessionContext and the underlying JIoEndpoint.  It's 
happening because the Vypser code has 2 methods using "synchronized":

 - 1 thd is doing an AsyncContext.dispatch from a synchronized method of 
BoshBackedSessionContext which hangs waiting for the JIoEndpoint synchronized 
socket wrapper in processSocketAsync
- the other thd is the async timeout in JIoEndpoint firing back into the 
BoshBackedSessionContext; he acquired the socket wrapper sync and is attempting 
to a different synchronized method on the same BoshBackedSessionContext

So, I'm going to remove the synchronized usage from the 
BoshBackedSessionContext and replace with a Lock/Condition using a tryLock with 
timeout and 1 retry.  I've used this approach before and it's typically a lot 
more performant and provides better control over situations like this.

Thx, bob

> >
> > Dan
> >
> >
> >>
> >> DEADLOCKED STACK INFORMATION
> >>
> >> Warning, the following threads are deadlocked :
> >> http-bio-192.168.230.133-443-exec-1329,
> >> http-bio-192.168.230.133-443-exec-685,
> >> http-bio-192.168.230.133-443-exec-687
> >>
> >> "http-bio-192.168.230.133-443-exec-685" daemon prio=5 BLOCKED
> >>
> org.apache.tomcat.util.net.JIoEndpoint.processSocketAsync(JIoEndpoint.java:55
> 6)
> >>
> org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:
> 365)
> >>
> org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Proce
> ssor.java:848)
> >>org.apache.coyote.Request.action(Request.java:344)
> >>
> org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:22
> 2)
> >>
> org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:18
> 1)
> >>
> org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:17
> 5)
> >>
> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.write0(
> BoshBackedSessionContext.java:251)
> >>
> org.apache.vysper.xmpp.extension.xep0124.BoshHandler.terminateSession(Bos
> hHand

(7.0.40) Seeing deadlock followed by maxThread usage using a Async Servlet AsyncContext.dispatch with BIO

[Bob DeRemer]

  java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   java.lang.Thread.run(Unknown Source)


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: Does JSR-356 provide a way for a client to pass security info on connect?

[Bob DeRemer]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, September 05, 2013 1:33 PM
> To: Tomcat Users List
> Subject: Re: Does JSR-356 provide a way for a client to pass security info on
> connect?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Bob,
> 
> On 9/5/13 12:32 PM, Bob DeRemer wrote:
> >> -Original Message- From: André Warnier [mailto:a...@ice-sa.com]
> >> Sent: Thursday, September 05, 2013 10:04 AM To: Tomcat Users List
> >> Subject: Re: Does JSR-356 provide a way for a client to pass security
> >> info on connect?
> >>
> >> And when you have done and solved the problem, would you be nice and
> >> post some summary on the list as a conclusion to this thread ? This
> >> way other people who would encounter the same issue later may find
> >> some useful pointers to the solution. (Or even better, write an
> >> article for the Tomcat WiKi)
> >
> > Absolutely, would love to!
> 
> Or, come to this fall's Apache Bar Camp* in Washington, DC and give an
> informal presentation on your exploits with Websocket in Tomcat 7.
> 
Hi chris,

That would be great.  Once you know the WHEN and WHERE, let me know.  If 
available, I'll definitely try to make it.   I'm just up in PA, so that's only 
a 2 hr drive.

Thx,bob

> - -chris
> 
> * Details to follow. The organizers (I'm one) are meeting this evening for 
> beers,
> so you know we'll get something accomplished.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJSKMBQAAoJEBzwKT+lPKRYWUMP/igIgZyN2xZsw8WghisyLdq
> I
> 57KvNQTcw2A5RWZIurhCIFuGljDv6E3oWFC/nGAUTY9m74UObBtQsRjlXK/pTrC0
> h3o9txPhPINoKj6CLUpYI2GvDKUW1yR9TRzpJYUoCsVW/YYnp5nsdek3SI4+7Ua9
> I4WsnuRwayfZEWSgP7Rn4q8AmQanBFyHmdWgXmpN9n7IQG8hX9tqCSkkhPfJG
> 97X
> a5vVxqKgBh3MFYW1SpnvFn7uCkCY7shfED2BJhruWVZgnaQAVn/I7dVWCj8Xzrg
> g
> YObM//PGyNceh9wzDU4bwHz9tYQ+XKruMLW7c7yneRgLsKisNc1+orM12zMLpC
> 9f
> Ap+U8zX7Yi7CgQXvdTOkPjrYddEzJL75pNLhj0AfZMTr3XCeVBfmpRAY5dcwd+qq
> +gEKscff9od2koLG3LLSBwps4LVjnfYHPCNkQ+qhKc5DpKKpMmIQOSidTwFnY817
> TJU3/SgXR81y/HdR4NqoLL9N98KqRDlkpZVsXn9NpWQEbazx2875C6CFDmW/8W
> 6H
> BPPR7SR+6/hp15AqFmyOKyOgISdeaReMlhvAFtjxKIy38xmb39bXfJqN17ZPDr2x
> jx3tGD+GRQ0odDblaipp1IwjCW47XXE65gO6Y3p4KydaxtUrcr7P0iQ2/HO9B4Wl
> KigIasG+QYOKqqMw9fWV
> =u0iB
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Does JSR-356 provide a way for a client to pass security info on connect?

[Bob DeRemer]

> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Thursday, September 05, 2013 10:04 AM
> To: Tomcat Users List
> Subject: Re: Does JSR-356 provide a way for a client to pass security info on
> connect?
> 
> Bob DeRemer wrote:
> >
> >> -Original Message-
> >> From: Niki Dokovski [mailto:nick...@gmail.com]
> >> Sent: Thursday, September 05, 2013 7:22 AM
> >> To: Tomcat Users List
> >> Subject: Re: Does JSR-356 provide a way for a client to pass security
> >> info on connect?
> >>
> >> On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski  wrote:
> >>
> >>>
> >>>
> >>> On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer
> >> wrote:
> >>>>
> >>>>> -Original Message-
> >>>>> From: André Warnier [mailto:a...@ice-sa.com]
> >>>>> Sent: Wednesday, September 04, 2013 3:59 PM
> >>>>> To: Tomcat Users List
> >>>>> Subject: Re: Does JSR-356 provide a way for a client to pass
> >>>>> security
> >>>> info on
> >>>>> connect?
> >>>>>
> >>>>> Bob DeRemer wrote:
> >>>>>> I'm curious if there's anything defined in JSR-356 to enable a
> >>>>>> client
> >>>> to pass
> >>>>> some security claims in the connect that would allow me to perform
> >>>>> an
> >>>> auth
> >>>>> check - prior to actually establishing the websocket connection.
> >>>>>> In an attempt to avoid a websocket DOS, I'm looking to see
> >>>>>> whether we
> >>>> can
> >>>>> do an auth check in the ServerEndpoint onOpen (or, possibly at an
> >>>> earlier
> >>>>> stage) - before the actual websocket gets established.  I know we
> >>>>> can
> >>>> do this at
> >>>>> the application level in the onMessage, but it'd be good to handle
> >>>>> this
> >>>> before
> >>>>> setting up the actual websocket if possible.
> >>>>>  From a not really websocket specialist :
> >>>>> As I recall, a websocket link starts with a normal HTTP request,
> >>>>> which
> >>>> then gets
> >>>>> upgraded to a websocket connection.  So it should be possible to
> >>>>> do AAA
> >>>> at the
> >>>>> initial HTTP stage, no ?
> >>>>>  From an earlier thread a couple of weeks (?) ago, it seems
> >>>>> however
> >>>> difficult to
> >>>>> retrieve some of that HTTP-level information later, when the
> >>>>> websocket connection is established.
> >>>>>
> >>>> Exactly what I am hoping to do: the WebSocket spec outlines the
> >>>> HTTP Upgrade handshake process.  During this handshake, a client
> >>>> should be able to send additional HTTP headers for this exact purpose 
> >>>> (i.e.
> >>>> cookies, auth tokens, etc.).  The server-side just needs an
> >>>> application-level hook that can be called that can effectively link
> >>>> into the pipeline - allowing/rejecting the establishment of the 
> >>>> connection.
> >>>>
> >>>> So, the big question(s):
> >>>> 1) does the tomcat client-side JSR impl provide a way to pass HTTP
> >>>> headers in the initial upgrade handshake
> >>>>
> >>> Yes
> >>> background
> >>>
> >>> http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointCo
> >>> nf
> >>> ig.Configurator.html#beforeRequest(java.util.Map)
> >>>
> >>> There is a mutuable headers map.
> >>>
> >>> 2) does the tomcat server-side JSR impl provide a way to hook into
> >>> the
> >>>> upgrade handshake and effectively allow/reject the connection
> >>>>
> >>> Yes and  (need to check further :)) background
> >>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEnd
> >>> po
> >>> intConfig.Configurator.html#modifyHandshake(javax.websocket.server.S
> >>> er verEndpointConfig, javax.websocket.server.HandshakeRequest,
> >>> javax.websocket.HandshakeResponse)
> >>>
> >>>
>

RE: Does JSR-356 provide a way for a client to pass security info on connect?

[Bob DeRemer]

> -Original Message-
> From: Niki Dokovski [mailto:nick...@gmail.com]
> Sent: Thursday, September 05, 2013 7:22 AM
> To: Tomcat Users List
> Subject: Re: Does JSR-356 provide a way for a client to pass security info on
> connect?
> 
> On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski  wrote:
> 
> >
> >
> >
> > On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer
> wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: André Warnier [mailto:a...@ice-sa.com]
> >> > Sent: Wednesday, September 04, 2013 3:59 PM
> >> > To: Tomcat Users List
> >> > Subject: Re: Does JSR-356 provide a way for a client to pass
> >> > security
> >> info on
> >> > connect?
> >> >
> >> > Bob DeRemer wrote:
> >> > > I'm curious if there's anything defined in JSR-356 to enable a
> >> > > client
> >> to pass
> >> > some security claims in the connect that would allow me to perform
> >> > an
> >> auth
> >> > check - prior to actually establishing the websocket connection.
> >> > >
> >> > > In an attempt to avoid a websocket DOS, I'm looking to see
> >> > > whether we
> >> can
> >> > do an auth check in the ServerEndpoint onOpen (or, possibly at an
> >> earlier
> >> > stage) - before the actual websocket gets established.  I know we
> >> > can
> >> do this at
> >> > the application level in the onMessage, but it'd be good to handle
> >> > this
> >> before
> >> > setting up the actual websocket if possible.
> >> > >
> >> >  From a not really websocket specialist :
> >> > As I recall, a websocket link starts with a normal HTTP request,
> >> > which
> >> then gets
> >> > upgraded to a websocket connection.  So it should be possible to do
> >> > AAA
> >> at the
> >> > initial HTTP stage, no ?
> >> >  From an earlier thread a couple of weeks (?) ago, it seems however
> >> difficult to
> >> > retrieve some of that HTTP-level information later, when the
> >> > websocket connection is established.
> >> >
> >>
> >> Exactly what I am hoping to do: the WebSocket spec outlines the HTTP
> >> Upgrade handshake process.  During this handshake, a client should be
> >> able to send additional HTTP headers for this exact purpose (i.e.
> >> cookies, auth tokens, etc.).  The server-side just needs an
> >> application-level hook that can be called that can effectively link
> >> into the pipeline - allowing/rejecting the establishment of the connection.
> >>
> >> So, the big question(s):
> >> 1) does the tomcat client-side JSR impl provide a way to pass HTTP
> >> headers in the initial upgrade handshake
> >>
> > Yes
> > background
> >
> > http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointConf
> > ig.Configurator.html#beforeRequest(java.util.Map)
> >
> > There is a mutuable headers map.
> >
> > 2) does the tomcat server-side JSR impl provide a way to hook into the
> >> upgrade handshake and effectively allow/reject the connection
> >>
> > Yes and  (need to check further :)) background
> > http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo
> > intConfig.Configurator.html#modifyHandshake(javax.websocket.server.Ser
> > verEndpointConfig, javax.websocket.server.HandshakeRequest,
> > javax.websocket.HandshakeResponse)
> >
> >
> > JSR 356 Specification  - 3.1.5 Handshake Modification I doesn't
> > particularly targets the rejection of the connection. The latter is
> > defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security
> > Model. which simply uses the "origin" mechanism.
> >
> 
> The status code of the response when connection should be dropped is 403
> Forbidden  defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which 
> is
> in relation to origin check.
> The  implementation in Tomcat calls checkOrigin either on the default
> configurator or on a custom supplied one.
> Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade
> method

Awesome - I'll start looking into this today!  
-thx, bob

> 
> cheers
> Niki
> 
> 
> 
> >
> >
> >
> >
> >
> >> >
> >> > ---
> >> > -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >

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

RE: Does JSR-356 provide a way for a client to pass security info on connect?

[Bob DeRemer]

> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Wednesday, September 04, 2013 3:59 PM
> To: Tomcat Users List
> Subject: Re: Does JSR-356 provide a way for a client to pass security info on
> connect?
> 
> Bob DeRemer wrote:
> > I'm curious if there's anything defined in JSR-356 to enable a client to 
> > pass
> some security claims in the connect that would allow me to perform an auth
> check - prior to actually establishing the websocket connection.
> >
> > In an attempt to avoid a websocket DOS, I'm looking to see whether we can
> do an auth check in the ServerEndpoint onOpen (or, possibly at an earlier
> stage) - before the actual websocket gets established.  I know we can do this 
> at
> the application level in the onMessage, but it'd be good to handle this before
> setting up the actual websocket if possible.
> >
>  From a not really websocket specialist :
> As I recall, a websocket link starts with a normal HTTP request, which then 
> gets
> upgraded to a websocket connection.  So it should be possible to do AAA at the
> initial HTTP stage, no ?
>  From an earlier thread a couple of weeks (?) ago, it seems however difficult 
> to
> retrieve some of that HTTP-level information later, when the websocket
> connection is established.
> 

Exactly what I am hoping to do: the WebSocket spec outlines the HTTP Upgrade 
handshake process.  During this handshake, a client should be able to send 
additional HTTP headers for this exact purpose (i.e. cookies, auth tokens, 
etc.).  The server-side just needs an application-level hook that can be called 
that can effectively link into the pipeline - allowing/rejecting the 
establishment of the connection. 

So, the big question(s): 
1) does the tomcat client-side JSR impl provide a way to pass HTTP headers in 
the initial upgrade handshake
2) does the tomcat server-side JSR impl provide a way to hook into the upgrade 
handshake and effectively allow/reject the connection

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


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

RE: is there a GA timeframe for 7.0 w/ jsr-356?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, September 04, 2013 5:30 PM
> To: Tomcat Users List
> Subject: Re: is there a GA timeframe for 7.0 w/ jsr-356?
> 
> On 04/09/2013 22:26, Bob DeRemer wrote:
> > With the 7.0 dev branch supporting jsr-356 for a couple weeks, I
> > wanted to see if there is a timeframe yet for a 7.0 GA release w/ jsr-356
> support?
> 
> It is stalled waiting for a native connector release that is required for 
> correct
> operation when using WebSocket with the APR/native HTTP connector.
> 
> Apart from that, it has been good to go for a while.

Excellent, thx
> 
> Mark
> 
> >
> >
> >
> > 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
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

is there a GA timeframe for 7.0 w/ jsr-356?

[Bob DeRemer]

With the 7.0 dev branch supporting jsr-356 for a couple weeks, I wanted to see 
if there is a timeframe yet for a 7.0 GA release w/ jsr-356 support?

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

Does JSR-356 provide a way for a client to pass security info on connect?

[Bob DeRemer]

I'm curious if there's anything defined in JSR-356 to enable a client to pass 
some security claims in the connect that would allow me to perform an auth 
check - prior to actually establishing the websocket connection.

In an attempt to avoid a websocket DOS, I'm looking to see whether we can do an 
auth check in the ServerEndpoint onOpen (or, possibly at an earlier stage) - 
before the actual websocket gets established.  I know we can do this at the 
application level in the onMessage, but it'd be good to handle this before 
setting up the actual websocket if possible.

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: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, September 03, 2013 4:46 PM
> To: Tomcat Users List
> Subject: Re: is it possible to dynamically add servlets and websocket 
> endpoints
> during startup based on our own configuration settings?
> 
> On 03/09/2013 21:35, Bob DeRemer wrote:
> 
> > Just getting around to trying this - maybe a stupid question, but how do I 
> > get
> access to the WsServerContainer instance?
> 
> From the ServletContext. You want the attribute called
> "javax.websocket.server.ServerContainer"

Thanks, I got the ServerContainer and can now call addEndpoint, but it expects 
the class I pass in to have the @ServerEndpoint annotation.   I removed the 
annotation because Tomcat was ALWAYS adding any pojo with that annotation, and 
my goal is to only add ServerEndpoints that I read in from my own 
configuration.  Is there a way to do this?

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


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

RE: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, August 23, 2013 8:40 AM
> To: Tomcat Users List
> Subject: Re: is it possible to dynamically add servlets and websocket 
> endpoints
> during startup based on our own configuration settings?
> 
> On 23/08/2013 13:28, Bob DeRemer wrote:
> >
> >
> >> -Original Message-
> >> From: Mark Thomas [mailto:ma...@apache.org]
> >> Sent: Friday, August 23, 2013 8:14 AM
> >> To: Tomcat Users List
> >> Subject: Re: is it possible to dynamically add servlets and websocket
> >> endpoints during startup based on our own configuration settings?
> >>
> >> On 22/08/2013 19:32, Bob DeRemer wrote:
> >>> I'm in the process of developing a configurable server application
> >>> which must handle various protocols, but the respective endpoints
> >>> must be configurable.  Specifically, I would like to
> >>> programmatically add both HTTP servlet(s) as well as WebSocket
> >>> Servlets/Endpoints during the contextInitialized call [based on our
> >>> own configuration settings], as opposed to having all servlets in
> >>> web.xml or annotated classes loaded automatically.
> >>>
> >>> Is this possible in Tomcat 7; and, if yes, are there any examples?
> >>> I know the Endpoint aspect of the question depends on JSR-356 being
> >>> back-ported.
> >>
> >> Yes, it is possible.
> >>
> >> There are some examples in the unit tests:
> >>
> >> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/co
> >> re/Test
> >> StandardContext.java?view=annotate
> >>
> >> Look for calls to addServlet(...)
> >
> > Great!  So, how do I tell Tomcat NOT to load anything in the first place?
> 
> Exclude the JARs containing the Servlets with an absolute-ordering in web.xml
> 
> >  Can I still use Annotation on my servlets, or will I have to use an 
> > interface-
> based approach?
> 
> I don't believe @WebServlet has any effect when adding Servlets via
> addServlet()
> 
> > Also, how about for the JSR-356 Endpoints?  Is there an addEndpoint(...) 
> > call?
> 
> Yes on ServerContainer, as long as you do it before any of them are used.
> 
Just getting around to trying this - maybe a stupid question, but how do I get 
access to the WsServerContainer instance?  

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


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

RE: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, August 23, 2013 8:14 AM
> To: Tomcat Users List
> Subject: Re: is it possible to dynamically add servlets and websocket 
> endpoints
> during startup based on our own configuration settings?
> 
> On 22/08/2013 19:32, Bob DeRemer wrote:
> > I'm in the process of developing a configurable server application
> > which must handle various protocols, but the respective endpoints must
> > be configurable.  Specifically, I would like to programmatically add
> > both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during
> > the contextInitialized call [based on our own configuration settings],
> > as opposed to having all servlets in web.xml or annotated classes
> > loaded automatically.
> >
> > Is this possible in Tomcat 7; and, if yes, are there any examples?  I
> > know the Endpoint aspect of the question depends on JSR-356 being
> > back-ported.
> 
> Yes, it is possible.
> 
> There are some examples in the unit tests:
> 
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/Test
> StandardContext.java?view=annotate
> 
> Look for calls to addServlet(...)

Great!  So, how do I tell Tomcat NOT to load anything in the first place?  Can 
I still use Annotation on my servlets, or will I have to use an interface-based 
approach?

Also, how about for the JSR-356 Endpoints?  Is there an addEndpoint(...) call?

-thx again

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


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

is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?

[Bob DeRemer]

I'm in the process of developing a configurable server application which must 
handle various protocols, but the respective endpoints must be configurable.  
Specifically, I would like to programmatically add both HTTP servlet(s) as well 
as WebSocket Servlets/Endpoints during the contextInitialized call [based on 
our own configuration settings], as opposed to having all servlets in web.xml 
or annotated classes loaded automatically.

Is this possible in Tomcat 7; and, if yes, are there any examples?  I know the 
Endpoint aspect of the question depends on JSR-356 being back-ported.

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: standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, August 22, 2013 1:37 PM
> To: Tomcat Users List
> Subject: Re: standalone use of Tomcat 8 websocket-api.jar
> getWebSocketContainer returning null
> 
> On 22/08/2013 17:39, Bob DeRemer wrote:
> > I'm trying to use the Tomcat8 jsr client functionality in a standalone
> > java client.  I'm trying to use the minimal number of jars, so I
> > gabbed websocket-api.jar ONLY.  When I call
> > ContainerProvider.getWebSocketContainer(), it returns null.
> >
> > Do I need another jar to resolve this on the client?
> 
> Yes. You need tomcat-websocket.jar (the implementation) and its dependencies
> (tomcat-juli.jar and tomcat-util.jar). It is possible to split the 
> implementation
> into client and server but we haven't done that. It isn't like the JARs are 
> that big
> anyway.

Not a problem, I just wanted to figure out the minimal as opposed to taking all 
of them

-thx

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


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

standalone use of Tomcat 8 websocket-api.jar getWebSocketContainer returning null

[Bob DeRemer]

I'm trying to use the Tomcat8 jsr client functionality in a standalone java 
client.  I'm trying to use the minimal number of jars, so I gabbed 
websocket-api.jar ONLY.  When I call ContainerProvider.getWebSocketContainer(), 
it returns null.

Do I need another jar to resolve this on the client?

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: Tomcat 7.0.42 closing websocket without any error receiving WebSocket ContinuationFrames

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, August 16, 2013 3:18 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 7.0.42 closing websocket without any error receiving
> WebSocket ContinuationFrames
> 
> On 16/08/2013 20:01, Bob DeRemer wrote:
> >
> >
> >> -Original Message-
> >> From: Mark Thomas [mailto:ma...@apache.org]
> >> Sent: Friday, August 16, 2013 1:40 PM
> >> To: Tomcat Users List
> >> Subject: Re: Tomcat 7.0.42 closing websocket without any error
> >> receiving WebSocket ContinuationFrames
> >>
> >> On 16/08/2013 18:08, Bob DeRemer wrote:
> >>> Hi Tomcat community,
> >>>
> >>> Has anyone had a large WS message sent as the response to an
> >>> outbound call?  We have a scenario where the request causes a 300K
> >>> WS message to be sent back as the "response".  The client is sending
> >>> multiple WS continuation frames and after a couple of frames are
> >>> successfully sent, Tomcat just closes the websocket connection.  I
> >>> the response fits in a single frame, it's fine.
> >>>
> >>> Where can I look to try and troubleshoot this?
> >>
> >> My first stop would be something like Wireshark to check that what
> >> the client is sending is valid.
> >>
> >> If the input is valid then there isn't much logging in the Tomcat 7
> >> non-JSR356 WebSocket implementation so I'd probably move on to remote
> >> debugging to see what is going on.
> >>
> >
> > Assuming the continuation frames are ok, what code in the non-jsr IMPL
> should I set some breakpoints in?
> 
> I'd start with org.apache.catalina.websocket.WsFrame.nextFrame(...)
> 
> You may need to go up or down the stack from there depending on where the
> problem lies.

Sounds good, thx!

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


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

RE: Tomcat 7.0.42 closing websocket without any error receiving WebSocket ContinuationFrames

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, August 16, 2013 1:40 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 7.0.42 closing websocket without any error receiving
> WebSocket ContinuationFrames
> 
> On 16/08/2013 18:08, Bob DeRemer wrote:
> > Hi Tomcat community,
> >
> > Has anyone had a large WS message sent as the response to an outbound
> > call?  We have a scenario where the request causes a 300K WS message
> > to be sent back as the "response".  The client is sending multiple WS
> > continuation frames and after a couple of frames are successfully
> > sent, Tomcat just closes the websocket connection.  I the response
> > fits in a single frame, it's fine.
> >
> > Where can I look to try and troubleshoot this?
> 
> My first stop would be something like Wireshark to check that what the client 
> is
> sending is valid.
> 
> If the input is valid then there isn't much logging in the Tomcat 7
> non-JSR356 WebSocket implementation so I'd probably move on to remote
> debugging to see what is going on.
>

Assuming the continuation frames are ok, what code in the non-jsr IMPL should I 
set some breakpoints in?
 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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

Tomcat 7.0.42 closing websocket without any error receiving WebSocket ContinuationFrames

[Bob DeRemer]

Hi Tomcat community,

Has anyone had a large WS message sent as the response to an outbound call?  We 
have a scenario where the request causes a 300K WS message to be sent back as 
the "response".  The client is sending multiple WS continuation frames and 
after a couple of frames are successfully sent, Tomcat just closes the 
websocket connection.  I the response fits in a single frame, it's fine.

Where can I look to try and troubleshoot this?

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: Any concrete timeline for JSR-356 in Tomcat 7?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, August 07, 2013 1:40 PM
> To: Tomcat Users List
> Subject: Re: Any concrete timeline for JSR-356 in Tomcat 7?
> 
> On 07/08/2013 18:59, Bob DeRemer wrote:
> > Hi Mark,
> >
> > This is a follow-up to my previous question about the tomcat 7 servlet
> > websocket deprecation:
> > http://marc.info/?l=tomcat-user&m=137580047908854&w=2
> >
> > We've discussed this internally and believe we need to look at switching to
> the JSR-based server-side implementation.  How we approach this will be
> determined by when JSR-356 will be ready.   Can you comment on the
> following:
> >
> >
> > 1)  When do you expect to have JSR-356 released on Tomcat 7?
> 
> Early September. Once bug 55314 has been solved, I plan to start the back-port
> to 7.0.x.
> 
> > 2)  How long do you anticipate the release cycle to be for Tomcat 8 - 
> > from
> the recent initial alpha release until it's GA?
> 
> Based on past experience, 6-9 months. However, a lot of that is out of our
> control. What will really drive this is user uptake of Tomcat 8 and folks 
> creating
> bug reports for issues they find (like the issue Dan Mikusa reported a little
> earlier).
> 
> 
> > Our assumption is that JSR-356 will be ready in Tomcat 7 long before Tomcat
> 8 is GA.
> 
> Agreed.
> 
> > The critical factor for us will be WHEN that happens.  We're tentatively
> looking at a release in October that will have websocket support.  As a 
> result, if
> Tomcat 7 JSR support is ready in September, we could begin work on Tomcat 8
> RC1, then back-port our JSR server code to Tomcat 7 and release on time with
> the new implementation.  If, however, Tomcat 7 JSR support won't be ready
> until October, then we'll have to plan on releasing with the existing Servlet
> implementation.
> >
> > I understand dates constantly change based on priorities, but if you can
> provide any clarification that would be great.
> 
> Hope the above helps.
> 
> Mark
> 

Thanks, Mark - very helpful!

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


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

RE: Any concrete timeline for JSR-356 in Tomcat 7?

[Bob DeRemer]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, August 07, 2013 6:35 PM
> To: Tomcat Users List
> Subject: Re: Any concrete timeline for JSR-356 in Tomcat 7?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Bob,
> 
> On 8/7/13 1:40 PM, Mark Thomas wrote:
> > On 07/08/2013 18:59, Bob DeRemer wrote:
> >> Hi Mark,
> >>
> >> This is a follow-up to my previous question about the tomcat 7
> >> servlet websocket deprecation:
> >> http://marc.info/?l=tomcat-user&m=137580047908854&w=2
> >>
> >> We've discussed this internally and believe we need to look at
> >> switching to the JSR-based server-side implementation.  How we
> >> approach this will be determined by when JSR-356 will be ready.
> >> Can you comment on the following:
> >>
> >>
> >> 1)  When do you expect to have JSR-356 released on Tomcat 7?
> >
> > Early September. Once bug 55314 has been solved, I plan to start the
> > back-port to 7.0.x.
> >
> >> 2)  How long do you anticipate the release cycle to be for
> >> Tomcat 8 - from the recent initial alpha release until it's GA?
> >
> > Based on past experience, 6-9 months. However, a lot of that is out of
> > our control. What will really drive this is user uptake of Tomcat 8
> > and folks creating bug reports for issues they find (like the issue
> > Dan Mikusa reported a little earlier).
> 
> It would be great if you (Bob) could give Tomcat 8 rigorous testing in your
> environment. The more bugs you find and report the faster Tomcat
> 8 can come to GA. Even if you go to production with Tomcat 7, consider running
> in development with Tomcat 8. If it's working for you, then feel free to go to
> production with an alpha release of Tomcat 8 :)
> 
> I've started to deploy Tomcat 8 into some my development environments for
> just this reason. We don't use any of the crazy new-ish features of the Java
> Servlet Specification, so I'll have a good environment for regression testing 
> for
> basic services, resource-loading, etc. We have some production services that
> are very basic where I may consider deploying an alpha version of Tomcat just
> to get some performance, etc. data. Rolling-back to Tomcat 7 for me is as easy
> as editing a property file and bouncing the service so it's very cheap for me 
> to
> provide this kind of testing for the community.
> 
> - -chris

Thanks, Chris - that's along the lines of what we're planning to do

Based on Mark's reply that JSR-356 should be in Tomcat 7 in early September, 
that should allow us to re-implement our server-side WS endpoints/handling 
against the JSR api - testing first against Tomcat 8 RC, then copying it back 
for use in Tomcat 7.

-bob

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJSAsuYAAoJEBzwKT+lPKRY7AQQAItT/LwJF8iGtXc5PihltsKT
> VrAUKdDB4PlQHdFicZQ08njIbTSJPkz9106Fr79vdJa0PKCkHmB1M+qDylTr1gk6
> L7yARvCh8DmSukX/TwOrufUegbE71i+eBHln23qBCSDu6nvAMKkCo8UWIj3cquO
> D
> a4bax0AYYNK83vaAjAGc16kmcz33L4mfMgSY5xynLwNsZJkBEoTInKprUKvLBiBr
> 0bBF/O7oYvuZDxvCGgeGi90vpfEYfmujuHfrqa5ira+KVAcwBdDmgOS6nhmYn791
> 6Mj+m67Q9ygm32umpEqpgm9xI4a576w9av91+CiR1iBuEEDlDAEuM3XdJ1y0my
> FZ
> 8RyX0ldzc/Z9a75sMZlRyCSo0jUXZjsLvC7jCm8FMDcRT9sXqDIGR4gMglriEaJ1
> MhX8VZ/Ikd1dUVhPCLT02tJmneMZxYgSipGHjdnAQLhoOfedAnc2IHoIF7oVfDv1
> D8QXsAQCKY48f2CwlzTbYeLvwuq0GVIRVfn+WB4tq9luXA7vGOeEcqtssqQlTcCN
> EE3Vm0hQOavh793l0FI2aNN/cbjYvyi5g6SQBnIwVkjW6MZ41VKfBsmx2+1osncl
> +gij9KTMkMw5jhS4lb55Qb3AfdU9L9Z31NEM7c+GU2RBA7ddZ/93EdDXjbW/Rc3
> Y
> EHO74vyNeSMZuP5j6JC7
> =tppT
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Any concrete timeline for JSR-356 in Tomcat 7?

[Bob DeRemer]

Hi Mark,

This is a follow-up to my previous question about the tomcat 7 servlet 
websocket deprecation: http://marc.info/?l=tomcat-user&m=137580047908854&w=2

We've discussed this internally and believe we need to look at switching to the 
JSR-based server-side implementation.  How we approach this will be determined 
by when JSR-356 will be ready.   Can you comment on the following:


1)  When do you expect to have JSR-356 released on Tomcat 7?

2)  How long do you anticipate the release cycle to be for Tomcat 8 - from 
the recent initial alpha release until it's GA?

Our assumption is that JSR-356 will be ready in Tomcat 7 long before Tomcat 8 
is GA.  The critical factor for us will be WHEN that happens.  We're 
tentatively looking at a release in October that will have websocket support.  
As a result, if Tomcat 7 JSR support is ready in September, we could begin work 
on Tomcat 8 RC1, then back-port our JSR server code to Tomcat 7 and release on 
time with the new implementation.  If, however, Tomcat 7 JSR support won't be 
ready until October, then we'll have to plan on releasing with the existing 
Servlet implementation.

I understand dates constantly change based on priorities, but if you can 
provide any clarification that would be great.

Thanks,
Bob

RE: Is the current Tomcat 7 servlet websocket implementation being deprecated?

[Bob DeRemer]

> -Original Message-
> From: Niki Dokovski [mailto:nick...@gmail.com]
> Sent: Tuesday, August 06, 2013 9:12 AM
> To: Tomcat Users List
> Subject: Re: Is the current Tomcat 7 servlet websocket implementation being
> deprecated?
> 
> On Tue, Aug 6, 2013 at 3:22 PM, Bob DeRemer
> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Mark Thomas [mailto:ma...@apache.org]
> > > Sent: Tuesday, August 06, 2013 3:59 AM
> > > To: Tomcat Users List
> > > Subject: Re: Is the current Tomcat 7 servlet websocket
> > > implementation
> > being
> > > deprecated?
> > >
> > > On 06/08/2013 03:54, Bob DeRemer wrote:
> > > > I've seen some mention on the user and dev mailing lists that the
> > > > current servlet-based websocket implementation will be deprecated
> > > > due to the implementation of the JSR-356.  We are currently
> > > > implementing a Tomcat 7-based websocket server implementation that
> > > > we hoped could scale up to at least 50K concurrent connections [or
> > > > more], but are concerned if there are any known issues and/or
> > > > limitations with the websocket implementation in Tomcat 7.
> > >
> > > No known issues or limitations but the JSR-356 will be ported to
> > > 7.0.x
> > and the
> > > current WebSocket implementation deprecated shortly (hopefully in
> > > the
> > next
> > > few weeks).
> > >
> > > > We are currently trying to test how high Tomcat 7 will scale with
> > > > regards to the maximum number of concurrent websocket connections,
> > > > but have already hit some problems with only 200+ concurrent
> connections.
> > > > Perhaps it's our multi-threaded client, or Tomcat configuration -
> > > > not sure at this point.  We have the Tomcat Connector configured
> > > > with
> > > > maxConnections=5 and maxThreads=1000, so 200 concurrent
> > > > connections shouldn't be a problem.
> > >
> > > It should scale but won't scale as well as the JSR-356
> > > implementation is
> > the
> > > current Tomcat 7 implementation is blocking within a frame.
> > >
> > > > If anyone could elaborate on the Tomcat 7 servlet websocket
> > > > implementation stability from a highly concurrent aspect that
> > > > would be great.  Additionally, if anyone has achieved 10(s) of
> > > > 1000(s) of concurrent websocket connections with Tomcat 7, can you
> > > > share how Tomcat was configured, what OS it was running on, and
> > > > what client library you used in testing this?
> > >
> > > I don't have any references for that but will be adding something to
> > > the
> > unit
> > > tests.
> > >
> > > Mark
> > >
> >
> > Thanks for the information.  If you have an reference examples for
> > server-side code based on JSR356, as well as a drop of Tomcat that
> > supports it, that would be a good place to start.
> >
> > There are several resources you can check:
> 1. Check Java EE 7 samples and documentation related to JSR 356. The jsr is
> part of Java EE 7 soecs (included in Web Profile as well).
> 2. Checkout Tomcat 8 source tree and check junit tests under
> org.apache.tomcat.websocket packages 3. Google it and check some of the
> blogs currently written on the subject.
> 

FINAL QUESTION on this thread:

* with the understanding that the existing Tomcat 7 logic is being deprecated, 
I have to ask:  could/should it be used in production - specifically if we know 
we're going to be expecting it to handle 50K+ concurrent connections?

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

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

RE: Is the current Tomcat 7 servlet websocket implementation being deprecated?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, August 06, 2013 3:59 AM
> To: Tomcat Users List
> Subject: Re: Is the current Tomcat 7 servlet websocket implementation being
> deprecated?
> 
> On 06/08/2013 03:54, Bob DeRemer wrote:
> > I've seen some mention on the user and dev mailing lists that the
> > current servlet-based websocket implementation will be deprecated due
> > to the implementation of the JSR-356.  We are currently implementing a
> > Tomcat 7-based websocket server implementation that we hoped could
> > scale up to at least 50K concurrent connections [or more], but are
> > concerned if there are any known issues and/or limitations with the
> > websocket implementation in Tomcat 7.
> 
> No known issues or limitations but the JSR-356 will be ported to 7.0.x and the
> current WebSocket implementation deprecated shortly (hopefully in the next
> few weeks).
> 
> > We are currently trying to test how high Tomcat 7 will scale with
> > regards to the maximum number of concurrent websocket connections, but
> > have already hit some problems with only 200+ concurrent connections.
> > Perhaps it's our multi-threaded client, or Tomcat configuration - not
> > sure at this point.  We have the Tomcat Connector configured with
> > maxConnections=5 and maxThreads=1000, so 200 concurrent
> > connections shouldn't be a problem.
> 
> It should scale but won't scale as well as the JSR-356 implementation is the
> current Tomcat 7 implementation is blocking within a frame.
> 
> > If anyone could elaborate on the Tomcat 7 servlet websocket
> > implementation stability from a highly concurrent aspect that would be
> > great.  Additionally, if anyone has achieved 10(s) of 1000(s) of
> > concurrent websocket connections with Tomcat 7, can you share how
> > Tomcat was configured, what OS it was running on, and what client
> > library you used in testing this?
> 
> I don't have any references for that but will be adding something to the unit
> tests.
> 
> Mark
> 

Thanks for the information.  If you have an reference examples for server-side 
code based on JSR356, as well as a drop of Tomcat that supports it, that would 
be a good place to start.

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


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

RE: any known problems using Tomcat 7.0.42 apr/native (windows) with websockets?

[Bob DeRemer]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, August 06, 2013 3:56 AM
> To: Tomcat Users List
> Subject: Re: any known problems using Tomcat 7.0.42 apr/native (windows)
> with websockets?
> 
> On 06/08/2013 03:45, Bob DeRemer wrote:
> > QUESTION
> >
> > Is anyone aware of any problems using the apr/native connector +
> > websockets in Tomcat 7.0.42?
> 
> I'm not aware of any reports.
> 
> > BACKGROUND
> >
> > We are trying to see how many concurrent websocket connections Tomcat
> > will handle running on Windows Server.   We wrote a multi-threaded java
> > console app that spins up a thread-per simulated websocket client.  In
> > each thread, we are using a separate Ning websocket client.
> > Unfortunately, we can't connect more than a few connections before we
> > start getting websocket errors.
> 
> What sort of errors?

I believe the connection was being closed unexpectedly

> 
> > If we change the connector to use NIO, the sporadic connection errors
> > seem to go away, but then we find that after about 200 connections,
> > the communication seems to hang.  This happens if all connections are
> > made from a single test client instance or spread across multiple
> > client instances.
> 
> That suggests at least some issue with APR/native and WebSocket.
> 
> > We're trying to determine where the problem lies and if it's in our
> > use of Ning in a multi-threaded client app, Tomcat connector
> > configuration, use of Tomcat websockets on Windows or something else.
> 
> The focus in Tomcat 7 is going to move to the JSR356 implementation pretty
> soon. I'd suggest looking at that rather than putting effort into Tomcat 7's
> current implementation.

Are there any examples for what must be written server-side?
Also, is there a version of Tomcat (7 or 8) that has this functionality 
available to test against?

> 
> > If anyone has any suggestions, I would greatly appreciate it.  If you
> > need additional information, please don't hesitate to ask.
> 
> I'll look into adding a concurrent client test to the Tomcat unit tests.
> 
> Mark
> 

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


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

Is the current Tomcat 7 servlet websocket implementation being deprecated?

[Bob DeRemer]

I've seen some mention on the user and dev mailing lists that the current 
servlet-based websocket implementation will be deprecated due to the 
implementation of the JSR-356.  We are currently implementing a Tomcat 7-based 
websocket server implementation that we hoped could scale up to at least 50K 
concurrent connections [or more], but are concerned if there are any known 
issues and/or limitations with the websocket implementation in Tomcat 7.

We are currently trying to test how high Tomcat 7 will scale with regards to 
the maximum number of concurrent websocket connections, but have already hit 
some problems with only 200+ concurrent connections.  Perhaps it's our 
multi-threaded client, or Tomcat configuration - not sure at this point.  We 
have the Tomcat Connector configured with maxConnections=5 and 
maxThreads=1000, so 200 concurrent connections shouldn't be a problem.

If anyone could elaborate on the Tomcat 7 servlet websocket implementation 
stability from a highly concurrent aspect that would be great.  Additionally, 
if anyone has achieved 10(s) of 1000(s) of concurrent websocket connections 
with Tomcat 7, can you share how Tomcat was configured, what OS it was running 
on, and what client library you used in testing this?

Thanks in advance,

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

any known problems using Tomcat 7.0.42 apr/native (windows) with websockets?

[Bob DeRemer]

QUESTION
Is anyone aware of any problems using the apr/native connector + websockets in 
Tomcat 7.0.42?

BACKGROUND
We are trying to see how many concurrent websocket connections Tomcat will 
handle running on Windows Server.   We wrote a multi-threaded java console app 
that spins up a thread-per simulated websocket client.  In each thread, we are 
using a separate Ning websocket client.  Unfortunately, we can't connect more 
than a few connections before we start getting websocket errors.

If we change the connector to use NIO, the sporadic connection errors seem to 
go away, but then we find that after about 200 connections, the communication 
seems to hang.  This happens if all connections are made from a single test 
client instance or spread across multiple client instances.

We're trying to determine where the problem lies and if it's in our use of Ning 
in a multi-threaded client app, Tomcat connector configuration, use of Tomcat 
websockets on Windows or something else.

If anyone has any suggestions, I would greatly appreciate it.  If you need 
additional information, please don't hesitate to ask.

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

Any known issues using Tomcat for container/app management, but netty for communication

[Bob DeRemer]

Hi Tomcat Community,

GOAL:
My goal is to use Netty for multiple-protocol communication handling, but run 
inside Tomcat to leverage the overall application lifecycle support 
(deployment, control, monitoring, etc.). 

To achieve this, I plan to disable all Connectors and use Netty for the actual 
communication.  The appserver/listener model makes it very simple to manage our 
app and control the startup/shutdown lifecycle.  This is very beneficial from 
an overall operations, management and support standpoint.  We just need to 
leverage Netty's communication infrastructure.

QUESTION:
Does anyone know of any problem with the approach I've described - 
specifically, using Tomcat's appserver lifecycle management functionality, but 
disabling all Tomcat Connectors and using Netty for all of our application 
communication?

NOTE: Tomcat is dedicated to our application, so we don't have to worry about 
sharing a tomcat installation with other applications.


Thanks in advance for any comments/suggestions.


Bob DeRemer
Senior Director, Architecture and Development

http://www.thingworx.com


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

RE: periodic (60 sec) problem from Vysper bosh servlet embedded in Tomcat 7.0.23

[Bob DeRemer]

Tomcat 7.0.23 64-bit on windows server 2008 R2 64-bit

-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Wednesday, January 11, 2012 4:30 AM
To: Tomcat Users List
Subject: Re: periodic (60 sec) problem from Vysper bosh servlet embedded in 
Tomcat 7.0.23

On 10/01/2012 21:04, Bob DeRemer wrote:
> Tomcat Community,
> 
>  
> 
> I'm not sure if this should be posted here or on the Mina/Vysper list, 
> but since the problem seems to be around Jetty Servlet3 continuation 
> functionality within the context of Tomcat, I thought I'd post here first.

Which version of Tomcat, exactly?


p

> PROBLEM
> 
> We're using vysper in an embedded mode and have modified the 
> BoshServlet to work in the context of our web application.  The Vysper 
> bosh servlet seems to make use of Jetty servlet3 continuation, and 
> we're getting the following stack trace every 60 seconds.  60 seconds 
> seems to be the default bosh session timeout when there is no activity:
> 
>  
> 
> I'm not sure what's going on with the low-level servlet3 continuation 
> stuff, but if anyone has any suggestions/recommendations, I'd greatly 
> appreciate it.
> 
>  
> 
> Thanks,
> 
> Bob
> 
>  
> 
> SEVERE: null
> 
> _java.lang.IllegalStateException_: Calling [asyncDispatch()] is not 
> valid for a request with Async state [DISPATCHING]
> 
>   at
> org.apache.coyote.AsyncStateMachine.asyncDispatch(_AsyncStateMachine.j
> ava:256_)
> 
>   at
> org.apache.coyote.http11.Http11AprProcessor.actionInternal(_Http11AprP
> rocessor.java:468_)
> 
>   at
> org.apache.coyote.http11.AbstractHttp11Processor.action(_AbstractHttp1
> 1Processor.java:834_)
> 
>   at org.apache.coyote.Request.action(_Request.java:344_)
> 
>   at
> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
> ava:185_)
> 
>   at
> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
> ava:146_)
> 
>   at
> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
> ava:140_)
> 
>   at
> org.eclipse.jetty.continuation.Servlet3Continuation.resume(_Servlet3Co
> ntinuation.java:153_)
> 
>   at
> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.writ
> e0(_BoshBackedSessionContext.java:233_)
> 
>   at
> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.requ
> estExpired(_BoshBackedSessionContext.java:451_)
> 
>   at
> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.acce
> ss$000(_BoshBackedSessionContext.java:46_)
> 
>   at
> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext$1.on
> Timeout(_BoshBackedSessionContext.java:605_)
> 
>   at
> org.eclipse.jetty.continuation.Servlet3Continuation$2.onTimeout(_Servl
> et3Continuation.java:90_)
> 
>   at
> org.apache.catalina.core.AsyncListenerWrapper.fireOnTimeout(_AsyncList
> enerWrapper.java:45_)
> 
>   at
> org.apache.catalina.core.AsyncContextImpl.timeout(_AsyncContextImpl.ja
> va:118_)
> 
>   at
> org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(_CoyoteAdapt
> er.java:292_)
> 
>   at
> org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(_Abstra
> ctHttp11Processor.java:1515_)
> 
>   at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(_
> AbstractProtocol.java:523_)
> 
>       at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(_AprEndpoin
> t.java:1817_)
> 
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> 
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source)
> 
>   at java.lang.Thread.run(Unknown Source)
> 
>  
> 
>  
> 
>  
> 
> *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
> 
>  
> 


-- 

[key:62590808]


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

periodic (60 sec) problem from Vysper bosh servlet embedded in Tomcat 7.0.23

[Bob DeRemer]

Tomcat Community,

I'm not sure if this should be posted here or on the Mina/Vysper list, but 
since the problem seems to be around Jetty Servlet3 continuation functionality 
within the context of Tomcat, I thought I'd post here first.

PROBLEM
We're using vysper in an embedded mode and have modified the BoshServlet to 
work in the context of our web application.  The Vysper bosh servlet seems to 
make use of Jetty servlet3 continuation, and we're getting the following stack 
trace every 60 seconds.  60 seconds seems to be the default bosh session 
timeout when there is no activity:

I'm not sure what's going on with the low-level servlet3 continuation stuff, 
but if anyone has any suggestions/recommendations, I'd greatly appreciate it.

Thanks,
Bob

SEVERE: null
java.lang.IllegalStateException: Calling [asyncDispatch()] is not valid for a 
request with Async state [DISPATCHING]
  at 
org.apache.coyote.AsyncStateMachine.asyncDispatch(AsyncStateMachine.java:256)
  at 
org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:468)
  at 
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834)
  at org.apache.coyote.Request.action(Request.java:344)
  at 
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:185)
  at 
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:146)
  at 
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:140)
  at 
org.eclipse.jetty.continuation.Servlet3Continuation.resume(Servlet3Continuation.java:153)
  at 
org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.write0(BoshBackedSessionContext.java:233)
  at 
org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.requestExpired(BoshBackedSessionContext.java:451)
  at 
org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.access$000(BoshBackedSessionContext.java:46)
  at 
org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext$1.onTimeout(BoshBackedSessionContext.java:605)
  at 
org.eclipse.jetty.continuation.Servlet3Continuation$2.onTimeout(Servlet3Continuation.java:90)
  at 
org.apache.catalina.core.AsyncListenerWrapper.fireOnTimeout(AsyncListenerWrapper.java:45)
  at 
org.apache.catalina.core.AsyncContextImpl.timeout(AsyncContextImpl.java:118)
  at 
org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:292)
  at 
org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1515)
  at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:523)
  at 
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1817)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
  at java.lang.Thread.run(Unknown Source)



Bob DeRemer
Senior Director, Architecture and Development

[cid:image001.png@01CCCFB1.909A3CD0]
http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986

RE: HOW TO detect what app server you're running in

[Bob DeRemer]

Good to know, thanks

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Wednesday, October 26, 2011 7:47 AM
To: Tomcat Users List
Subject: Re: HOW TO detect what app server you're running in

Note, that this method is unreliable.

1) The actual value can be configured by server administrator.
2) There are 3-rd party repackaged distributions of Tomcat, which may/should 
change the value.

It would be better to rely on presence of certain features that you are going 
to use, or let the user configure your webapp.

Best regards,
Konstantin Kolinko

2011/10/25 Bob DeRemer :
> Yeah, that should do it - should have remembered that - I'm already using 
> this - purely for diagnostic info.
>
> Thanks, guys!
>
> -Original Message-
> From: Ronald Klop (Mailing List) [mailto:ronald-mailingl...@base.nl]
> Sent: Tuesday, October 25, 2011 7:39 AM
> To: Tomcat Users List
> Subject: Re: HOW TO detect what app server you're running in
>
> Does this help?
>
>     public void doGet(HttpServletRequest request, HttpServletResponse 
> response)
>             throws ServletException, IOException {
>         System.out.println("serverinfo: " + 
> getServletContext().getServerInfo());
>     }
>
>  Ronald.
>
> Op dinsdag, 25 oktober 2011 13:33 schreef Bob DeRemer 
> :
>>
>>
>>
>>  I may need to use some Tomcat-specific code in my web app.  As a result, I 
>> would like to detect [if possible] when I'm running in Tomcat, so I can 
>> invoke the logic.   If anyone knows how best to do this, ideally with some 
>> sample java code, that'd be great.
>>
>>  Thanks,
>>  Bob
>>
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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


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

RE: HOW TO detect what app server you're running in

[Bob DeRemer]

Yeah, that should do it - should have remembered that - I'm already using this 
- purely for diagnostic info.

Thanks, guys!

-Original Message-
From: Ronald Klop (Mailing List) [mailto:ronald-mailingl...@base.nl] 
Sent: Tuesday, October 25, 2011 7:39 AM
To: Tomcat Users List
Subject: Re: HOW TO detect what app server you're running in

Does this help?

 public void doGet(HttpServletRequest request, HttpServletResponse response)
 throws ServletException, IOException {
 System.out.println("serverinfo: " + 
getServletContext().getServerInfo());
 }

 Ronald.

Op dinsdag, 25 oktober 2011 13:33 schreef Bob DeRemer 
:
> 
>   
>  
>  I may need to use some Tomcat-specific code in my web app.  As a result, I 
> would like to detect [if possible] when I'm running in Tomcat, so I can 
> invoke the logic.   If anyone knows how best to do this, ideally with some 
> sample java code, that'd be great.
>  
>  Thanks,
>  Bob
>  
> 
> 
>  
> 

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

HOW TO detect what app server you're running in

[Bob DeRemer]

I may need to use some Tomcat-specific code in my web app.  As a result, I 
would like to detect [if possible] when I'm running in Tomcat, so I can invoke 
the logic.   If anyone knows how best to do this, ideally with some sample java 
code, that'd be great.

Thanks,
Bob

RE: JAR locked in Tomcat after using addUrl to dynamically add JAR to running webapp

[Bob DeRemer]

Thanks Mark, I appreciate the offer.  Let me dig into a bit today - based on 
your steps.   if I can't get anywhere, I'll gladly take you up on your offer.  
What is the best way to communicate out-of-band if I need to get you a snapshot?

-bob

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, October 21, 2011 7:42 AM
To: Tomcat Users List
Subject: Re: JAR locked in Tomcat after using addUrl to dynamically add JAR to 
running webapp

On 21/10/2011 12:22, Bob DeRemer wrote:
> Hi Mark,
> 
> With regard to using Tomcat in production, that was meant 
> sarcastically - the team has done a nice job on later Tomcat 6 and 
> Tomcat 7 32/64-bit installations - including Windows Service support, 
> etc. - nice work.

That comment was more aimed at the archives than you ;)

> With regard to using YourKit, I have a licensed copy, but must be 
> missing something - where can I look to see what is holding a 
> reference to the JAR?  I've used it for memory analysis and CPU 
> profiling - primarily, but I'm not sure where to look for JAR 
> references.

File locks can be tricky to pin down. I usually do something along the lines of:
1. Take a memory snapshot
2. Switch to the object view
3. Search for the name of the JAR
4. Trace the GC roots of a promising looking object

Normally, the JAR name appears in a String for a JarFile or File object and 
that traces back to whatever is holding the reference.

I'd be happy to take a look at the snapshot for you if you can put the snapshot 
somewhere where I can download it.

Mark


> 
> Thanks, Bob
> 
> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Friday, October 21, 2011 2:46 AM To:
> Tomcat Users List Subject: Re: JAR locked in Tomcat after using addUrl 
> to dynamically add JAR to running webapp
> 
> On 21/10/2011 03:00, Bob DeRemer wrote:
>> While I can appreciate the desire to never use Windows, that isn't  
>> reality in many of the industries that use our product, so running  
>> Tomcat on windows can't be considered an oddity or edge case.  If it 
>> is, we better look for another app server.
> 
> If that were the case, the Tomcat devs wouldn't have put the 
> investment they have into the Windows installer in recent months (auto 
> detection of 32 or 64 bit JRE, greater control over ports, multiple 
> service installs of the same version, ...)
> 
>> With regard to finding a solution, I'll try the antiJarLocking 
>> setting, but I don't have any problem with any other JARS, so I don't 
>> hold out much hope for this fixing my problem.  I may look at  
>> upgrading to JDK 7 - which has added a "close" method to the 
>> URLClassLoader.  Perhaps this might fix it.
> 
> Maybe.
> 
>> If anyone else has any other ideas why ONLY JARs added via the addURL 
>> "hack" I've shown below don't get unloaded when the WEBAPP is 
>> shutdown - vs stopping Tomcat completely, I would greatly appreciate 
>> it.
> 
> You need to understand the root cause. I'd recommend getting a 
> profiler (I use YourKit since they give free copies to Tomcat
> committers) and finding out exactly what is holding references to 
> those JARs. Once you know that the next questions are 1. What creates 
> those references and 2. How to get rid of them.
> 
> Mark
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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


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

RE: JAR locked in Tomcat after using addUrl to dynamically add JAR to running webapp

[Bob DeRemer]

Hi Mark,

With regard to using Tomcat in production, that was meant sarcastically - the 
team has done a nice job on later Tomcat 6 and Tomcat 7 32/64-bit installations 
- including Windows Service support, etc. - nice work.

With regard to using YourKit, I have a licensed copy, but must be missing 
something - where can I look to see what is holding a reference to the JAR?  
I've used it for memory analysis and CPU profiling - primarily, but I'm not 
sure where to look for JAR references.

Thanks,
Bob

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, October 21, 2011 2:46 AM
To: Tomcat Users List
Subject: Re: JAR locked in Tomcat after using addUrl to dynamically add JAR to 
running webapp

On 21/10/2011 03:00, Bob DeRemer wrote:
> While I can appreciate the desire to never use Windows, that isn't 
> reality in many of the industries that use our product, so running 
> Tomcat on windows can't be considered an oddity or edge case.  If it 
> is, we better look for another app server.

If that were the case, the Tomcat devs wouldn't have put the investment they 
have into the Windows installer in recent months (auto detection of
32 or 64 bit JRE, greater control over ports, multiple service installs of the 
same version, ...)

> With regard to finding a solution, I'll try the antiJarLocking 
> setting, but I don't have any problem with any other JARS, so I don't 
> hold out much hope for this fixing my problem.  I may look at 
> upgrading to JDK 7 - which has added a "close" method to the 
> URLClassLoader.  Perhaps this might fix it.

Maybe.

> If anyone else has any other ideas why ONLY JARs added via the addURL 
> "hack" I've shown below don't get unloaded when the WEBAPP is shutdown 
> - vs stopping Tomcat completely, I would greatly appreciate it.

You need to understand the root cause. I'd recommend getting a profiler (I use 
YourKit since they give free copies to Tomcat committers) and finding out 
exactly what is holding references to those JARs. Once you know that the next 
questions are 1. What creates those references and 2.
How to get rid of them.

Mark

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


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

RE: JAR locked in Tomcat after using addUrl to dynamically add JAR to running webapp

[Bob DeRemer]

While I can appreciate the desire to never use Windows, that isn't reality in 
many of the industries that use our product, so running Tomcat on windows can't 
be considered an oddity or edge case.  If it is, we better look for another app 
server.

With regard to finding a solution, I'll try the antiJarLocking setting, but I 
don't have any problem with any other JARS, so I don't hold out much hope for 
this fixing my problem.  I may look at upgrading to JDK 7 - which has added a 
"close" method to the URLClassLoader.  Perhaps this might fix it.

If anyone else has any other ideas why ONLY JARs added via the addURL "hack" 
I've shown below don't get unloaded when the WEBAPP is shutdown - vs stopping 
Tomcat completely, I would greatly appreciate it.

Thanks,
Bob

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Thursday, October 20, 2011 6:07 PM
To: Tomcat Users List
Subject: RE: JAR locked in Tomcat after using addUrl to dynamically add JAR to 
running webapp

> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
> Subject: RE: JAR locked in Tomcat after using addUrl to dynamically 
> add JAR to running webapp

> I am not using a local app context and everything I've seen recommends 
> NOT using antijarlocking in production settings.

Yes, except for the fact that you're doing rather odd things, including running 
on Windows...

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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


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

RE: JAR locked in Tomcat after using addUrl to dynamically add JAR to running webapp

[Bob DeRemer]

I am not using a local app context and everything I've seen recommends NOT 
using antijarlocking in production settings.

Thx,
bob

-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Thursday, October 20, 2011 5:53 PM
To: Tomcat Users List
Subject: Re: JAR locked in Tomcat after using addUrl to dynamically add JAR to 
running webapp

On 20/10/2011 18:18, Bob DeRemer wrote:
> Hi Tomcat Community:
> 
> BACKGROUND:
> I have a Servlet-based WEBAPP that is running in Tomcat7, JDK 1.6.0_27 on 
> Windows Server 2008 R2 64-bit - all 64-bit.  We make use of class.newInstance 
> quite a bit as we have a fairly modular, interface-based system, and create 
> class instances on the fly.  As part of our extensibility,  I'm also using a 
> pretty well documented "hack" [The code is listed below]  for dynamically 
> adding JAR(s) so they are accessible immediately without stopping our WEBAPP 
> or the actual Tomcat server process.   This process has worked great for both 
> JAR(s) in the WEB-INF/lib and for ones we dynamically added - until you try 
> and stop the WEBAPP via the Tomcat manager app.
> 
> PROBLEM:
> This solution for dynamically loading JARs worked great as long as we 
> start/stop the actual Tomcat server process, but I found out the JAR(s) that 
> I have been dynamically loading this way are not released when you stop the 
> WEBAPP.  I am using SysInternals Process Explorer to monitor the open file 
> handles of the Tomcat7 process.  I can see that when I stop the WEBAPP, the 
> dynamically loaded JAR is still referenced.
> 
> QUESTION:
> I made an assumption that calling 
> Thread.currentThread().getContextClassLoader() would provide me the 
> classloader of my WEBAPP - which should be the same classloader that all the 
> JARs in the WEB-INF/lib are in.  We control the WEBAPP, so I assumed this was 
> a safe assumption.
> 
> The usage of the dynamically loaded JAR(s) is no different than the default 
> JAR(s) in WEB-INF/lib.  None of the WEB-INF/lib JARs are left open when we 
> stop the WEBAPP - only the JAR(s) that are loaded via the "addUrl" approach 
> below.
> 
> I have been through a number of online articles when I first created this 
> logic - including a PDF by Ted Neward [while at Developmentor] that described 
> these approaches, but am not sure how to troubleshoot this further now.
> 
> If anyone has an answer or any suggestions, I would greatly appreciate it.

Do you have 'antiJarLocking' enabled on the Context?


p

> Thanks in advance,
> Bob
> 
> 
> Code to dynamically load JAR(s):
> 
> public static void loadJarOnTheFly(File jarFile) throws IOException
> {
>   Class[] parameters = new Class[]{URL.class};
> 
>   // IMPORTANT: MUST use the webapp classloader - so derived extension 
> classes can resolve their base classes
>   ClassLoader contextClassLoader = 
> Thread.currentThread().getContextClassLoader();
> 
>   // cast to a URL class loader so we can additional JAR(s) to the search 
> path
> URLClassLoader webappClassLoader = (URLClassLoader)contextClassLoader;
> 
> Class sysclass = URLClassLoader.class;
> 
> try
> {
> URL jarUrl = jarFile.toURI().toURL();
> 
> Method method = sysclass.getDeclaredMethod("addURL", parameters);
> method.setAccessible(true);
>     method.invoke(webappClassLoader, new Object[]{ jarUrl });
> }
> catch (Throwable t)
> {
> throw new IOException("Error, could not add URL to system 
> classloader");
> }
> }
> 
> 
> 
> Bob DeRemer
> Senior Director, Architecture and Development
> 
> http://www.thingworx.com<http://www.thingworx.com/>
> Skype: bob.deremer
> O: 717.505.7923
> M: 717.881.3986
> 
> 



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

JAR locked in Tomcat after using addUrl to dynamically add JAR to running webapp

[Bob DeRemer]

Hi Tomcat Community:

BACKGROUND:
I have a Servlet-based WEBAPP that is running in Tomcat7, JDK 1.6.0_27 on 
Windows Server 2008 R2 64-bit - all 64-bit.  We make use of class.newInstance 
quite a bit as we have a fairly modular, interface-based system, and create 
class instances on the fly.  As part of our extensibility,  I'm also using a 
pretty well documented "hack" [The code is listed below]  for dynamically 
adding JAR(s) so they are accessible immediately without stopping our WEBAPP or 
the actual Tomcat server process.   This process has worked great for both 
JAR(s) in the WEB-INF/lib and for ones we dynamically added - until you try and 
stop the WEBAPP via the Tomcat manager app.

PROBLEM:
This solution for dynamically loading JARs worked great as long as we 
start/stop the actual Tomcat server process, but I found out the JAR(s) that I 
have been dynamically loading this way are not released when you stop the 
WEBAPP.  I am using SysInternals Process Explorer to monitor the open file 
handles of the Tomcat7 process.  I can see that when I stop the WEBAPP, the 
dynamically loaded JAR is still referenced.

QUESTION:
I made an assumption that calling 
Thread.currentThread().getContextClassLoader() would provide me the classloader 
of my WEBAPP - which should be the same classloader that all the JARs in the 
WEB-INF/lib are in.  We control the WEBAPP, so I assumed this was a safe 
assumption.

The usage of the dynamically loaded JAR(s) is no different than the default 
JAR(s) in WEB-INF/lib.  None of the WEB-INF/lib JARs are left open when we stop 
the WEBAPP - only the JAR(s) that are loaded via the "addUrl" approach below.

I have been through a number of online articles when I first created this logic 
- including a PDF by Ted Neward [while at Developmentor] that described these 
approaches, but am not sure how to troubleshoot this further now.

If anyone has an answer or any suggestions, I would greatly appreciate it.

Thanks in advance,
Bob


Code to dynamically load JAR(s):

public static void loadJarOnTheFly(File jarFile) throws IOException
{
  Class[] parameters = new Class[]{URL.class};

  // IMPORTANT: MUST use the webapp classloader - so derived extension 
classes can resolve their base classes
  ClassLoader contextClassLoader = 
Thread.currentThread().getContextClassLoader();

  // cast to a URL class loader so we can additional JAR(s) to the search 
path
URLClassLoader webappClassLoader = (URLClassLoader)contextClassLoader;

Class sysclass = URLClassLoader.class;

try
{
URL jarUrl = jarFile.toURI().toURL();

Method method = sysclass.getDeclaredMethod("addURL", parameters);
method.setAccessible(true);
method.invoke(webappClassLoader, new Object[]{ jarUrl });
}
catch (Throwable t)
{
throw new IOException("Error, could not add URL to system 
classloader");
}
}



Bob DeRemer
Senior Director, Architecture and Development

http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer
O: 717.505.7923
M: 717.881.3986

RE: HOW TO: re-deploy or undeploy a webapp when additional files are added after initial deployment

[Bob DeRemer]

Should YourKit be able to pinpoint this?  I've used it for memory and other 
profiling, but haven't used it to see what might be holding onto JARs after a 
webapp has been shutdown.

Thanks again,
Bob

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, August 02, 2011 3:52 AM
To: Tomcat Users List
Subject: Re: HOW TO: re-deploy or undeploy a webapp when additional files are 
added after initial deployment

On 02/08/2011 02:11, Bob DeRemer wrote:
> Hi Mark,
> 
> Actually, in the logs it does tell me that ExpandWar deleteDir failed.  
> This is because my "extensions" I have are actually JAR files that 
> we're dynamically loaded so we don't have to restart the webapp.  I'm 
> using the addUrl hack, but by casting the main webapp's
> Thread.currentThread().getContextClassLoader() to a URLClassLoader.
> From a dynamic loading standpoint, it works great!  It allows 
> extension classes in an extension JAR to derive from classes in our 
> built-in product JAR(s) loaded by the same [I'm assuming] webapp 
> classloader.
> 
> The problem is, when I shutdown/undeploy the webapp, everything else 
> gets deleted, but not the JAR(s) that are dynamically loaded.  Tomcat 
> should not be holding on to these because I am NOT using the System 
> class loader to load them.  Problem is, I'm not sure why these are not 
> being unloaded.

You'll need to get a profiler to see what is holding on to references to those 
JARs.

> Is there any way to force tomcat to release these?  I tried putting 
> the antiJARLocking="true" in the main Context.xml as well as a local 
> context.xml in META-INF and neither of these worked.

Without knowing what is holding on to the reference, it is pretty much 
impossible to determine the best way to solve this problem.

Mark

> 
> Thanks in advance, Bob
> 
> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Monday, August 01, 2011 3:44 PM To:
> Tomcat Users List Subject: Re: HOW TO: re-deploy or undeploy a webapp 
> when additional files are added after initial deployment
> 
> On 01/08/2011 20:32, Bob DeRemer wrote:
>> Thanks, but I need to do this in a production environment, where 
>> we're deploying/re-deploying a WAR and there is no eclipse IDE.  In  
>> addition, I am dynamically adding extensions to our webapp without  
>> having to restart our webapp, which is what republishing from Eclipse 
>> does.
> 
> Any messages in the logs? Tomcat 7 will report if it can't delete a 
> file. I don't recall if Tomcat 6 does.
> 
> If a file is under the docBase and is not deleted it is because 
> something (probably your app) still has the file open. You need to 
> close the files before you redeploy.
> 
> Mark
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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


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

RE: HOW TO: re-deploy or undeploy a webapp when additional files are added after initial deployment

[Bob DeRemer]

Also - I just looked at my local tomcat 6.0.32 server.xml and it has 
JreMemoryLeakPreventionListener on the Server element.  The implicit disabling 
of URL caching this is supposed to do must not have an effect on this scenario.

As an aside, when I used antiJARLocking + antiResourceLocking on the server's 
context.xml, it appeared to work, but that has other documented side effects - 
such as creating a bunch of garbage in the tomcat/temp directory.   As a 
result, this really isn't a solution for us.

Any suggestions on how we can get these JAR(s) not to be locked - without using 
the context attributes?

Thanks,
bob

-Original Message-----
From: Bob DeRemer [mailto:bob.dere...@thingworx.com] 
Sent: Monday, August 01, 2011 9:12 PM
To: Tomcat Users List
Subject: RE: HOW TO: re-deploy or undeploy a webapp when additional files are 
added after initial deployment

Hi Mark,

Actually, in the logs it does tell me that ExpandWar deleteDir failed.  This is 
because my "extensions" I have are actually JAR files that we're dynamically 
loaded so we don't have to restart the webapp.  I'm using the addUrl hack, but 
by casting the main webapp's Thread.currentThread().getContextClassLoader() to 
a URLClassLoader.  From a dynamic loading standpoint, it works great!  It 
allows extension classes in an extension JAR to derive from classes in our 
built-in product JAR(s) loaded by the same [I'm assuming] webapp classloader. 

The problem is, when I shutdown/undeploy the webapp, everything else gets 
deleted, but not the JAR(s) that are dynamically loaded.  Tomcat should not be 
holding on to these because I am NOT using the System class loader to load 
them.  Problem is, I'm not sure why these are not being unloaded.

Is there any way to force tomcat to release these?  I tried putting the 
antiJARLocking="true" in the main Context.xml as well as a local context.xml in 
META-INF and neither of these worked.

Thanks in advance,
Bob

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, August 01, 2011 3:44 PM
To: Tomcat Users List
Subject: Re: HOW TO: re-deploy or undeploy a webapp when additional files are 
added after initial deployment

On 01/08/2011 20:32, Bob DeRemer wrote:
> Thanks, but I need to do this in a production environment, where we're 
> deploying/re-deploying a WAR and there is no eclipse IDE.  In 
> addition, I am dynamically adding extensions to our webapp without 
> having to restart our webapp, which is what republishing from Eclipse 
> does.

Any messages in the logs? Tomcat 7 will report if it can't delete a file. I 
don't recall if Tomcat 6 does.

If a file is under the docBase and is not deleted it is because something 
(probably your app) still has the file open. You need to close the files before 
you redeploy.

Mark

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


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


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

RE: HOW TO: re-deploy or undeploy a webapp when additional files are added after initial deployment

[Bob DeRemer]

Hi Mark,

Actually, in the logs it does tell me that ExpandWar deleteDir failed.  This is 
because my "extensions" I have are actually JAR files that we're dynamically 
loaded so we don't have to restart the webapp.  I'm using the addUrl hack, but 
by casting the main webapp's Thread.currentThread().getContextClassLoader() to 
a URLClassLoader.  From a dynamic loading standpoint, it works great!  It 
allows extension classes in an extension JAR to derive from classes in our 
built-in product JAR(s) loaded by the same [I'm assuming] webapp classloader. 

The problem is, when I shutdown/undeploy the webapp, everything else gets 
deleted, but not the JAR(s) that are dynamically loaded.  Tomcat should not be 
holding on to these because I am NOT using the System class loader to load 
them.  Problem is, I'm not sure why these are not being unloaded.

Is there any way to force tomcat to release these?  I tried putting the 
antiJARLocking="true" in the main Context.xml as well as a local context.xml in 
META-INF and neither of these worked.

Thanks in advance,
Bob

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, August 01, 2011 3:44 PM
To: Tomcat Users List
Subject: Re: HOW TO: re-deploy or undeploy a webapp when additional files are 
added after initial deployment

On 01/08/2011 20:32, Bob DeRemer wrote:
> Thanks, but I need to do this in a production environment, where we're 
> deploying/re-deploying a WAR and there is no eclipse IDE.  In 
> addition, I am dynamically adding extensions to our webapp without 
> having to restart our webapp, which is what republishing from Eclipse 
> does.

Any messages in the logs? Tomcat 7 will report if it can't delete a file. I 
don't recall if Tomcat 6 does.

If a file is under the docBase and is not deleted it is because something 
(probably your app) still has the file open. You need to close the files before 
you redeploy.

Mark

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


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

RE: HOW TO: re-deploy or undeploy a webapp when additional files are added after initial deployment

[Bob DeRemer]

Thanks, but I need to do this in a production environment, where we're 
deploying/re-deploying a WAR and there is no eclipse IDE.  In addition, I am 
dynamically adding extensions to our webapp without having to restart our 
webapp, which is what republishing from Eclipse does.

-bob

-Original Message-
From: Chema [mailto:demablo...@gmail.com] 
Sent: Monday, August 01, 2011 3:02 PM
To: Tomcat Users List
Subject: Re: HOW TO: re-deploy or undeploy a webapp when additional files are 
added after initial deployment

> If anyone has any suggestions on how we can add files into the exploded 
> webapp structure and still perform undeploy/re-deploy of our webapp, I would 
> greatly appreciate it.  Or, if there's a way to tell tomcat to completely 
> remove the directory - regardless of additional files/directories, that would 
> probably work, too.
>

Eclipse Hellios' plugins to deploy web applications work fine for me.
You can try Eclipse IDE for Java EE Developers.

When I change any file deployed , it's automatically republished. And you can 
clean work folders from IDE.

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


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

HOW TO: re-deploy or undeploy a webapp when additional files are added after initial deployment

[Bob DeRemer]

I'm running Tomcat 6.0.32 on Windows Server 2008 R2.

I am running into a problem when managing our webapp via the Tomcat Manager 
App.  Specifically, if I add any files to our WEB-INF/extension directory in 
the exploded WAR directory after the initial deployment, an undeploy fails to 
completely remove our exploded webapp directory.  It removes everything that 
was in the WAR, but leaves the manually added files.  In addition, if we 
attempt to deploy a new WAR when this skeleton directory is left, the deploy 
says it's successful, but doesn't explode the new WAR.

If anyone has any suggestions on how we can add files into the exploded webapp 
structure and still perform undeploy/re-deploy of our webapp, I would greatly 
appreciate it.  Or, if there's a way to tell tomcat to completely remove the 
directory - regardless of additional files/directories, that would probably 
work, too.

The only other options I can think of would be installing these dynamic 
extensions outside the webapp, but that's not ideal since some of these 
extensions will be HTML/CSS content and we'd like to keep it all under the 
webapp root.

Thanks,

Bob DeRemer
Senior Director, Architecture and Development

http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer
O: 717.505.7923
M: 717.881.3986

RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

Awesome, thanks!

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, June 30, 2011 10:18 PM
To: Tomcat Users List
Subject: Re: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bob,

On 6/30/2011 10:07 PM, Bob DeRemer wrote:
> Thanks!  I know it's all open and online, I was just hoping someone 
> might be able to point me to some specific classes so I don't have to 
> pour through a lot of irrelevant code.

Tomcat's component for JSPs is called Jasper. Most of it can be found in the 
org.apache.jasper package and subpackages, bundled along with the rest of the 
Tomcat code.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4NLmwACgkQ9CaO5/Lv0PCQHwCdEQiiqlp6ooaR6ydHE4uTMtFe
HEsAoI2koCSUSozQT4sKJ5tTUMTZxKiU
=yAtC
-END PGP SIGNATURE-

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

RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

Thanks!  I know it's all open and online, I was just hoping someone might be 
able to point me to some specific classes so I don't have to pour through a lot 
of irrelevant code.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, June 30, 2011 10:04 PM
To: Tomcat Users List
Subject: Re: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bob,

On 6/30/2011 9:55 PM, Bob DeRemer wrote:
> I've verified that the WEB-INF/extensions will work, too.  The key 
> issue for us is being able to hot-deploy extension JAR(s) live without 
> restarting the webapp or Tomcat.  I began by seeing if Tomcat 
> supported find JAR(s) on non-standard locations so we can separate the 
> extensions.  These extensions to our core product will typically be 
> developed by 3rd parties.
> 
> So, I now need to look at creating my own classloader [it seems] 
> because even the VWL doesn't monitor for JAR additions and 
> automatically load them.  Again - if anyone knows how to do this, I 
> would really appreciate any direction to shorten my dev time.

Tomcat has a ClassLoader used for re-loading JSPs. A quick look at that shows 
there is no real magic there: it does not re-load itself in any way. Instead, 
some other component somewhere must be monitoring the JSP files for updates and 
orchestrating the disposal of the old ClassLoader (and the classes and 
instances loaded by it) and the creation of a new one.

I believe AXIS also has such a scheme for re-loading web services without 
bouncing the entire webapp.

All source code is available online, so you are free to read it all ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4NKxkACgkQ9CaO5/Lv0PBHdgCdEKO+q78Bg2sKCTHqo3j35Zw8
HC4An0CsvndY6prfajI/jrI45h7T2bF/
=GEfb
-END PGP SIGNATURE-

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

RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

I've verified that the WEB-INF/extensions will work, too.  The key issue for us 
is being able to hot-deploy extension JAR(s) live without restarting the webapp 
or Tomcat.  I began by seeing if Tomcat supported find JAR(s) on non-standard 
locations so we can separate the extensions.  These extensions to our core 
product will typically be developed by 3rd parties.

So, I now need to look at creating my own classloader [it seems] because even 
the VWL doesn't monitor for JAR additions and automatically load them.  Again - 
if anyone knows how to do this, I would really appreciate any direction to 
shorten my dev time.

Thanks,
Bob

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Thursday, June 30, 2011 7:17 PM
To: Tomcat Users List
Subject: Re: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

2011/7/1 Christopher Schultz :
>
> On 6/30/2011 11:27 AM, Konstantin Kolinko wrote:
>> 2011/6/30 Bob DeRemer :
>>>           virtualClasspath="/WEB-INF/lib/extensions/*.jar"/>
>>
>> The above should be an absolute path.
>>
>> You can use system variables, e.g.
>> ${catalina.base}/webapps/mywebapp/WEB-INF/lib/extensions/*.jar
>
> Hmm... does that mean that VirtualWebappLoader can't be used with 
> paths inside WAR files? Being able to support paths relative to the 
> webapp would be quite nice.

I think that should be some ${} property.

It either has
a) either to be given to the Digester when it parses the XML, so that it 
expands the property,
b) or Digester will leave it unexpanded (because it is unknown) and 
VirtualWebappLoader  will expand its value when starting.

Either way, there is a question of obtaining this path early and passing this 
information around.


Regarding the issue that I mentioned:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47939

It looks that the following (without "lib") will work:
 ${catalina.base}/webapps/mywebapp/WEB-INF/extensions/*.jar

Best regards,
Konstantin Kolinko

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


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

RE: UPDATE - RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

Thank you!

Since it looks like I need to create my own classloader [to get it to check my 
extensions folder "on the fly"], can you point me to some links or samples that 
show how to do this?  I can't believe more people haven't had to dynamically 
load JAR(s) to resolve classes "on the fly" for extensible applications that 
need to remain running.

-bob

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Thursday, June 30, 2011 12:25 PM
To: Tomcat Users List
Subject: Re: UPDATE - RE: how to use VirtualWebappLoader - either in 
META-INF/context.xml or programmatically on startup

2011/6/30 Bob DeRemer :
> I was able to get this to work.  I had a hunch, so I moved the extensions 
> folder outside the WEB-INF directory.    Any idea why these extra 
> repositories cannot be under the WEB-INF/lib folder ?

I think classes should be loadable, but IIRC annotation and resources scanning 
won't work for the. There was a bug about that and it was closed as WONTFIX.
The short version is that it is hard to differ between app's own WEB-INF and 
your directory, and WEB-INF is explicitly skipped to avoid scanning it twice.

>
> Also, ONE OTHER QUESTION:
>
> Is there a way to have new JAR(s) that get dropped into the extensions folder 
> picked up automatically [without] restarting the webapp or tomcat?

No, it is not possible. You need to restart the webapp.

>  We'd like to have the classloader actually fallback to reading from this 
> extensions location if I can't load it normally.
> * would this require a custom classloader that derived from 
> VirtualWebappLoader - so it would pickup existing extensions at startup, but 
> could also check/load the JAR(s) dynamically if it can't load them?
> ** if it does require a custom classloader, can someone point me to an 
> example of how to do this?

YMMV.  You may start reading with the ones implemented by Tomcat.
There is classloader for JSPs that supports reloading (if JspServlet is being 
run in "development"=true mode).

VirtualWebappLoader is not a classloader. It is just a component that 
configures one.

Best regards,
Konstantin Kolinko

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


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

UPDATE - RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

I was able to get this to work.  I had a hunch, so I moved the extensions 
folder outside the WEB-INF directory.Any idea why these extra repositories 
cannot be under the WEB-INF/lib folder ?

Also, ONE OTHER QUESTION: 

Is there a way to have new JAR(s) that get dropped into the extensions folder 
picked up automatically [without] restarting the webapp or tomcat?  We'd like 
to have the classloader actually fallback to reading from this extensions 
location if I can't load it normally.
* would this require a custom classloader that derived from VirtualWebappLoader 
- so it would pickup existing extensions at startup, but could also check/load 
the JAR(s) dynamically if it can't load them?
** if it does require a custom classloader, can someone point me to an example 
of how to do this?

Thanks again,
Bob

-Original Message-
From: Bob DeRemer [mailto:bob.dere...@thingworx.com] 
Sent: Thursday, June 30, 2011 11:53 AM
To: Tomcat Users List
Subject: RE: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

Thanks Konstantin, but that didn't do it.  I can see that Tomcat copies the 
context.xml over to /conf/Catalina/localhost and names it 
.xml.  Is there any way to printout the classpath my webapp is using 
in the context of tomcat - to try and debug this?

The exact contents is:


 


Do I need to do anything programmatically to enable this?

-bob

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Thursday, June 30, 2011 11:27 AM
To: Tomcat Users List
Subject: Re: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

2011/6/30 Bob DeRemer :
>           virtualClasspath="/WEB-INF/lib/extensions/*.jar"/>

The above should be an absolute path.

You can use system variables, e.g.
${catalina.base}/webapps/mywebapp/WEB-INF/lib/extensions/*.jar

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


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


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

RE: how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

Thanks Konstantin, but that didn't do it.  I can see that Tomcat copies the 
context.xml over to /conf/Catalina/localhost and names it 
.xml.  Is there any way to printout the classpath my webapp is using 
in the context of tomcat - to try and debug this?

The exact contents is:





Do I need to do anything programmatically to enable this?

-bob

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Thursday, June 30, 2011 11:27 AM
To: Tomcat Users List
Subject: Re: how to use VirtualWebappLoader - either in META-INF/context.xml or 
programmatically on startup

2011/6/30 Bob DeRemer :
>           virtualClasspath="/WEB-INF/lib/extensions/*.jar"/>

The above should be an absolute path.

You can use system variables, e.g.
${catalina.base}/webapps/mywebapp/WEB-INF/lib/extensions/*.jar

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


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

how to use VirtualWebappLoader - either in META-INF/context.xml or programmatically on startup

[Bob DeRemer]

We're running tomcat 6.0.32 64-bit on Windows Server 2008 R2.  We have a 
requirement to support pluggable extensions to our webapp.  We do not want the 
associated JAR(s) in the WEB-INF/lib directory.  Instead, we want to place them 
in a WEB-INF/lib/extensions folder that we created.

To do this, I need to inform my webapp class loader about the extra repository. 
 From looking at VirtualWebappLoader, this looks like just what I need.

Problem is - I can't seem to get this to work.  I have created a context.xml 
file and placed it in our META-INF folder.  The contents are:



   


>From reading the tomcat documentation, it seems like Tomcat should 
>automatically detect the context.xml file and add the classloader, but it 
>doesn't seem to be looking in this extra directory.  I've tried adding a path 
>attribute to the Context element, but that didn't help.

If anyone can clarify how to use this, I would greatly appreciate it.

Thanks in advance,
-bob

RE: HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

Very well stated and completely understood.  My gut is already telling me that 
trying to customize/extend Tomcat in this way is way outside the scope of how 
Tomcat was designed or intended to be used.  And, I would bet you're right with 
regard to parts of the Tomcat architecture having certain "HTTP expectations".

Thanks again for your risk assessment - this will help in making our decision 
on how to move forward.

-bob 

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Thursday, June 30, 2011 6:27 AM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

Hi.

To round up what I am trying to say :

Tomcat is a java servlet engine.  In the principle, there is nothing that says 
that it cannot handle protocols other than HTTP/HTTPS, and run servlets which 
handle other kinds of messages than HTTP/HTTPS messages.
However, my general impression is that
1) this is not being done very often
2) therefore, even apart from the Connectors, there may be quite a few aspects 
in Tomcat which are HTTP(S)-centric, and which have not really been 
investigated a lot with
non-HTTP(S) messages.
For example, there was a discussion recently on this list, concerning "HTTP 100 
Continue" 
  status codes, and if I remember correctly this implied that a Listener should 
be configured at the level of the Connector, and it also implied that this 
would trigger the immediate parsing of request headers as soon as a request 
came in.
Now I can quite easily imagine that this could be much more complicated if some 
requests which come in, are non-HTTP(S).

In summary, I have the feeling that creating a "discriminating Connector" which 
would dispatch HTTP(S)/XMPP requests as appropriate, could just be the tip of 
the iceberg, and that you could find yourself sucked into making many more 
changes than what you imagine at first.

Now take this with a grain of salt, since I am neither a java nor a Tomcat 
expert.  I just happen to remember the classic line which says that "90% of a 
software project is done in 90% of the time; the remaining 10% also."



Bob DeRemer wrote:
> Hi Andre,
> 
> Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well.  
> If we're able to share a port, it solves various IT administration issues 
> when deployed in corporate environments.  In addition, it will enable us to 
> have a single server process and ultimately a simpler overall architecture 
> because we won't have to configure/manage 2 separate server applications.  
> 
> I'm still not sure this is feasible or the best way to go, but it's worth the 
> investigation.  Given a lot of work I've done on the Microsoft side of 
> things, their WCF infrastructure provides a TCP port sharing service, which 
> is somewhat similar in nature to what we're looking to do.  At the end of the 
> day - both HTTP and XMPP are TCP-based.  So, if I can front a single port for 
> the incoming TCP request and then route it to the appropriate 
> protocol-specific endpoint, there would be some significant benefits to us 
> architecturally because we are not forced to break the functionality into 2 
> separate applications - unless we wanted to.
> 
> That said, if I can find a solution, we'll have to validate the performance 
> and stability - no doubt.
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Wednesday, June 29, 2011 3:30 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port 
> sharing
> 
> Pid wrote:
>> On 29/06/2011 19:51, Christopher Schultz wrote:
>>> Honestly, I'd look for a non-Tomcat-centric solution because it's 
>>> probably already been built elsewhere.
>>>
>>> -chris
>> Why is opening another port a problem?
>>
> 
> +1
> 
> I do not know XMPP, but from the original OP description it sounds 
> like a protocol which uses its own transport protocol, and normally 
> some other standard port than 80/443. (*)
> 
> Without even going into what kind of issues you may encounter at the Tomcat 
> level when trying to process requests/responses which are not HTTP/HTTPS, I 
> would also think that if you mix 2 different protocols on the same port, you 
> will be forcing whatever equipment/software which separates and dispatches 
> them, to look *inside* each TCP packet to determine which protocol this one 
> is about.  That in itself will introduce quite a bit of overhead.
> 
> Then again, if the connection is (sometimes) over SSL, that would also 
> probably mean that the packets have to be decrypted, even before their 
> HTTP/XMPP nature can be discriminated.
> 
> Looking at XMPP in

RE: HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

I'm not sure on the XMPP over HTTP, since we require the real-time always-on 
connectivity provided by XMPP.  I'll have to see exactly what XMPP over HTTP 
does under the hood.  We can't afford to have our XMPP connections doing 
long-polling or anything.

-bob

-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Thursday, June 30, 2011 3:45 AM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

On 30/06/2011 02:10, Bob DeRemer wrote:
> Chris,
> 
> Thanks for the feedback.  I haven't come across squid yet, so I will take a 
> look.  With regard to HTTP proxying, no, I don't want to do HTTP proxying.  I 
> would like to insert a TCP-based NIO request router in place of Tomcat's 
> Connector.  Specifically, I would like to do something similar to the Netty 
> Port Unification sample, but with HTTP AND XMPP protocols.  Netty has the 
> ability to inspect the incoming request and then get outta the way - adding 
> the appropriate Channel for processing the request.  
> 
> The problem I'm facing is that we're using Tomcat as our App Server and we 
> can't easily replace that with a non-servlet based solution at this point.   
> As a result, I was trying to determine if there is a way to create some type 
> of Tomcat extension that where I could do the initial request routing and 
> pass HTTP request on to the Tomcat's plumbing without running the built-in 
> HTTP connector(s).

You'd have to write your own connector implementation, or hack an existing one 
- in Tomcat 7.0 there's some work being done to consolidate the connector code, 
so you'd be wise to start there.

Is XMPP over HTTP a possibility, and if so could the applicable code run inside 
a Servlet?


Sounds like a 'square peg, round hole' type situation...


p



> Thanks,
> Bob
> 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, June 29, 2011 2:51 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port 
> sharing
> 
> Bob,
> 
> On 6/29/2011 1:10 PM, Bob DeRemer wrote:
>> I've scoured the net for information on how to do port sharing within 
>> the context of a Tomcat Servlet-based web application process.
>> While there's some discussion, there still doesn't appear to be any 
>> solutions [YET] - that I could find yet.
> 
>> What I need to do is the following:
> 
>> * receive both HTTP and XMPP traffic on a single port [either 80 or
>>   443 - depending on security configuration]
> 
>> * route the HTTP traffic to Tomcat's HTTP Connector [or
>>   sub-processing component] if possible
> 
>> * route the XMPP to an embedded Vysper server
> 
> All of the above should be doable using something like Squid. Does Squid do 
> pretty much everything?
> 
>> * ALL running in the context of a single Tomcat Server process
> 
> Oh.
> 
> You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people 
> who want HTTP proxying just use some other web server out in front of Tomcat 
> (like Apache httpd, Squid, Nginx, lighttpd, HTTP lb, etc.). I have to imagine 
> that at least one of those products can do content-detection to determine 
> where to route messages.
> 
> Does it /have to/ be Tomcat-based?
> 
>> This will enable us to leverage the power/investment in our servlet 
>> infrastructure and Vysper XMPP all together without having to open 
>> multiple ports.
> 
>> If this is possible in either Tomcat 6 or Tomcat 7, please let me 
>> know how I should go about this:
> 
>> * doing some custom extension in Tomcat (i.e. custom Tomcat
>>   connector that uses Netty for example)
> 
>> * or, some other approach ???
> 
> If you want to brute-force it, you could write a servlet Filter (or, better 
> yet, a Tomcat-specific Valve that runs before the request is mapped to a 
> webapp) to intercept the messages and proxy them over to your other 
> service(s). You'll have to do the HTTP proxying yourself, though.
> 
>> please advise on how you would recommend achieving our goal.
> 
> Honestly, I'd look for a non-Tomcat-centric solution because it's probably 
> already been built elsewhere.
> 
> -chris

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

RE: HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

Hi Andre,

Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well.  If 
we're able to share a port, it solves various IT administration issues when 
deployed in corporate environments.  In addition, it will enable us to have a 
single server process and ultimately a simpler overall architecture because we 
won't have to configure/manage 2 separate server applications.  

I'm still not sure this is feasible or the best way to go, but it's worth the 
investigation.  Given a lot of work I've done on the Microsoft side of things, 
their WCF infrastructure provides a TCP port sharing service, which is somewhat 
similar in nature to what we're looking to do.  At the end of the day - both 
HTTP and XMPP are TCP-based.  So, if I can front a single port for the incoming 
TCP request and then route it to the appropriate protocol-specific endpoint, 
there would be some significant benefits to us architecturally because we are 
not forced to break the functionality into 2 separate applications - unless we 
wanted to.

That said, if I can find a solution, we'll have to validate the performance and 
stability - no doubt.

Thanks,
Bob

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Wednesday, June 29, 2011 3:30 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

Pid wrote:
> On 29/06/2011 19:51, Christopher Schultz wrote:
>> Honestly, I'd look for a non-Tomcat-centric solution because it's 
>> probably already been built elsewhere.
>>
>> -chris
> 
> Why is opening another port a problem?
> 

+1

I do not know XMPP, but from the original OP description it sounds like a 
protocol which uses its own transport protocol, and normally some other 
standard port than 80/443. (*)

Without even going into what kind of issues you may encounter at the Tomcat 
level when trying to process requests/responses which are not HTTP/HTTPS, I 
would also think that if you mix 2 different protocols on the same port, you 
will be forcing whatever equipment/software which separates and dispatches 
them, to look *inside* each TCP packet to determine which protocol this one is 
about.  That in itself will introduce quite a bit of overhead.

Then again, if the connection is (sometimes) over SSL, that would also probably 
mean that the packets have to be decrypted, even before their HTTP/XMPP nature 
can be discriminated.

Looking at XMPP in Wikipedia, it looks like there is something called "XMPP 
over HTTP transport".  Is that what the OP has in mind ?




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

RE: HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

When installing into certain corporate environments, opening multiple ports can 
be a problem with IT.  By leveraging 80/443 for both protocols, we can 
eliminate this inevitable deployment problem.

-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Wednesday, June 29, 2011 3:02 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

On 29/06/2011 19:51, Christopher Schultz wrote:
> Honestly, I'd look for a non-Tomcat-centric solution because it's 
> probably already been built elsewhere.
> 
> -chris

Why is opening another port a problem?


p

RE: HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

Chris,

Thanks for the feedback.  I haven't come across squid yet, so I will take a 
look.  With regard to HTTP proxying, no, I don't want to do HTTP proxying.  I 
would like to insert a TCP-based NIO request router in place of Tomcat's 
Connector.  Specifically, I would like to do something similar to the Netty 
Port Unification sample, but with HTTP AND XMPP protocols.  Netty has the 
ability to inspect the incoming request and then get outta the way - adding the 
appropriate Channel for processing the request.  

The problem I'm facing is that we're using Tomcat as our App Server and we 
can't easily replace that with a non-servlet based solution at this point.   As 
a result, I was trying to determine if there is a way to create some type of 
Tomcat extension that where I could do the initial request routing and pass 
HTTP request on to the Tomcat's plumbing without running the built-in HTTP 
connector(s).

Thanks,
Bob

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, June 29, 2011 2:51 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bob,

On 6/29/2011 1:10 PM, Bob DeRemer wrote:
> I've scoured the net for information on how to do port sharing within 
> the context of a Tomcat Servlet-based web application process.
> While there's some discussion, there still doesn't appear to be any 
> solutions [YET] - that I could find yet.
> 
> What I need to do is the following:
> 
> * receive both HTTP and XMPP traffic on a single port [either 80 or
>   443 - depending on security configuration]
> 
> * route the HTTP traffic to Tomcat's HTTP Connector [or
>   sub-processing component] if possible
> 
> * route the XMPP to an embedded Vysper server

All of the above should be doable using something like Squid. Does Squid do 
pretty much everything?

> * ALL running in the context of a single Tomcat Server process

Oh.

You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people 
who want HTTP proxying just use some other web server out in front of Tomcat 
(like Apache httpd, Squid, Nginx, lighttpd, HTTP lb, etc.). I have to imagine 
that at least one of those products can do content-detection to determine where 
to route messages.

Does it /have to/ be Tomcat-based?

> This will enable us to leverage the power/investment in our servlet 
> infrastructure and Vysper XMPP all together without having to open 
> multiple ports.
> 
> If this is possible in either Tomcat 6 or Tomcat 7, please let me know 
> how I should go about this:
> 
> * doing some custom extension in Tomcat (i.e. custom Tomcat
>   connector that uses Netty for example)
> 
> * or, some other approach ???

If you want to brute-force it, you could write a servlet Filter (or, better 
yet, a Tomcat-specific Valve that runs before the request is mapped to a 
webapp) to intercept the messages and proxy them over to your other service(s). 
You'll have to do the HTTP proxying yourself, though.

> please advise on how you would recommend achieving our goal.

Honestly, I'd look for a non-Tomcat-centric solution because it's probably 
already been built elsewhere.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4LdBwACgkQ9CaO5/Lv0PDnegCfcTgMDFoAXELLl/dG2O+nDf1r
iSoAn08cn0AfOMfREMMYoS4IkcXJtHx7
=BUTa
-END PGP SIGNATURE-

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

HOW TO: create custom Tomcat 6 connector to do port sharing

[Bob DeRemer]

Hi Tomcat gurus:


I've scoured the net for information on how to do port sharing within the 
context of a Tomcat Servlet-based web application process.  While there's some 
discussion, there still doesn't appear to be any solutions [YET] - that I could 
find yet.



What I need to do is the following:



* receive both HTTP and XMPP traffic on a single port [either 80 or 443 - 
depending on security configuration]

* route the HTTP traffic to Tomcat's HTTP Connector [or sub-processing 
component] if possible

* route the XMPP to an embedded Vysper server

* ALL running in the context of a single Tomcat Server process



This will enable us to leverage the power/investment in our servlet 
infrastructure and Vysper XMPP all together without having to open multiple 
ports.



If this is possible in either Tomcat 6 or Tomcat 7, please let me know how I 
should go about this:

* doing some custom extension in Tomcat (i.e. custom Tomcat connector that uses 
Netty for example)

* or, some other approach ???



please advise on how you would recommend achieving our goal.



Thanks in advance,

Bob


Bob DeRemer
Senior Director, Architecture and Development

http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer
O: 717.505.7923
M: 717.881.3986