Re: Disabling hostname verification on websockets in Tomcat 8+

[V User]

Ah, that's it! I was using the TrustEverythingTrustManager
<https://javadoc.io/static/com.rabbitmq/amqp-client/4.12.0/com/rabbitmq/client/TrustEverythingTrustManager.html>
we
had around from the rabbitmq client library, which just
implements X509TrustManager, and I didn't realize that was significantly
different from X509ExtendedTrustManager. Looks like it's working now,
thanks!

On Fri, May 26, 2023 at 3:24 AM Mark Thomas  wrote:

> On 25/05/2023 22:52, V User wrote:
>
> > The how-to on websockets (
> > https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html) says
> that
> > you can bypass hostname verification with a custom TrustManager: "For
> > secure server endpoints, host name verification is enabled by default. To
> > bypass this verification (not recommended), it is necessary to provide a
> > custom SSLContext via the org.apache.tomcat.websocket.SSL_CONTEXT user
> > property. The custom SSLContext must be configured with a custom
> > TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The
> > desired verification (or lack of verification) can then be controlled by
> > appropriate implementations of the individual abstract methods."
>
> I have just confirmed that a custom trust manager that extends
> X509ExtendedTrustManager and provides NO-OPs implementations for all
> abstract methods works as expected with Java 8 (Temurin build
> 1.8.0_362-b09) and OpenJDK 21 EA build 24.
>
> > I did a trial using an "accept everything" TrustManager, but was still
> > seeing the same errors. Poking around with a debugger, it seems like the
> > JSSE "AbstractTrustManagerWrapper" runs the configured TrustManager
> checks,
> > and then runs its own "additional" checks, which is where things are
> > failing (
> >
> https://github.com/JetBrains/jdk8u_jdk/blob/94318f9185757cc33d2b8d527d36be26ac6b7582/src/share/classes/sun/security/ssl/SSLContextImpl.java#L1097
> ).
> > In particular, it seems like if the identity algorithm returned by
> > "getEndpointIdentificationAlgorithm" is non-null, it runs some identity
> > checks using X509TrustManagerImpl, regardless of what custom TrustManager
> > was set by the end user. I also found this Stackoverflow question:
> >
> https://stackoverflow.com/questions/51244136/tomcat-websocket-disable-hostname-verification
> ,
> > which led me to this hardcoded parameter in WsWebSocketContainer:
> >
> https://github.com/apache/tomcat/blob/db0c10ea25cc8984f72d700ea48f32aadc2fe2f4/java/org/apache/tomcat/websocket/WsWebSocketContainer.java#L928
> > .
> >
> > So, it seems to me that while you can disable *certificate* verification
> by
> > setting a custom TrustManager, you cannot disable *hostname*
> verification.
> > Is that correct, or am I missing some other option or parameter?
>
> Looks like you are missing something.
>
> I suggest you provide the source code for a simple test case that fails
> for you.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Disabling hostname verification on websockets in Tomcat 8+

[Mark Thomas]

On 25/05/2023 22:52, V User wrote:


The how-to on websockets (
https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html) says that
you can bypass hostname verification with a custom TrustManager: "For
secure server endpoints, host name verification is enabled by default. To
bypass this verification (not recommended), it is necessary to provide a
custom SSLContext via the org.apache.tomcat.websocket.SSL_CONTEXT user
property. The custom SSLContext must be configured with a custom
TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The
desired verification (or lack of verification) can then be controlled by
appropriate implementations of the individual abstract methods."


I have just confirmed that a custom trust manager that extends 
X509ExtendedTrustManager and provides NO-OPs implementations for all 
abstract methods works as expected with Java 8 (Temurin build 
1.8.0_362-b09) and OpenJDK 21 EA build 24.



I did a trial using an "accept everything" TrustManager, but was still
seeing the same errors. Poking around with a debugger, it seems like the
JSSE "AbstractTrustManagerWrapper" runs the configured TrustManager checks,
and then runs its own "additional" checks, which is where things are
failing (
https://github.com/JetBrains/jdk8u_jdk/blob/94318f9185757cc33d2b8d527d36be26ac6b7582/src/share/classes/sun/security/ssl/SSLContextImpl.java#L1097).
In particular, it seems like if the identity algorithm returned by
"getEndpointIdentificationAlgorithm" is non-null, it runs some identity
checks using X509TrustManagerImpl, regardless of what custom TrustManager
was set by the end user. I also found this Stackoverflow question:
https://stackoverflow.com/questions/51244136/tomcat-websocket-disable-hostname-verification,
which led me to this hardcoded parameter in WsWebSocketContainer:
https://github.com/apache/tomcat/blob/db0c10ea25cc8984f72d700ea48f32aadc2fe2f4/java/org/apache/tomcat/websocket/WsWebSocketContainer.java#L928
.

So, it seems to me that while you can disable *certificate* verification by
setting a custom TrustManager, you cannot disable *hostname* verification.
Is that correct, or am I missing some other option or parameter?


Looks like you are missing something.

I suggest you provide the source code for a simple test case that fails 
for you.


Mark

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

Disabling hostname verification on websockets in Tomcat 8+

[V User]

Hello,

I'm working through upgrading an application from Tomcat 7 to Tomcat 9, and
am running into an issue with hostname verification. The application
initiates websocket connections using SSL to several other servers by IP
address, and those servers' certificates either do not have any subject
alternative names (SAN) set, or have SANs that do not include their IP
address. As a result, we're getting SSL connection errors like "No subject
alternative names present" and "No subject alternative names matching IP
address  found".

(I understand that the correct solution here would be to update all our
servers to have certificates with proper SANs and make our
application initiate websockets using hostnames that match the SANs, but
that will take some time to do and I'm trying to figure out if there's a
workaround that will let us complete the upgrade to Tomcat 9 without having
to do a complete rollout of those changes first.)

The how-to on websockets (
https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html) says that
you can bypass hostname verification with a custom TrustManager: "For
secure server endpoints, host name verification is enabled by default. To
bypass this verification (not recommended), it is necessary to provide a
custom SSLContext via the org.apache.tomcat.websocket.SSL_CONTEXT user
property. The custom SSLContext must be configured with a custom
TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The
desired verification (or lack of verification) can then be controlled by
appropriate implementations of the individual abstract methods."

I did a trial using an "accept everything" TrustManager, but was still
seeing the same errors. Poking around with a debugger, it seems like the
JSSE "AbstractTrustManagerWrapper" runs the configured TrustManager checks,
and then runs its own "additional" checks, which is where things are
failing (
https://github.com/JetBrains/jdk8u_jdk/blob/94318f9185757cc33d2b8d527d36be26ac6b7582/src/share/classes/sun/security/ssl/SSLContextImpl.java#L1097).
In particular, it seems like if the identity algorithm returned by
"getEndpointIdentificationAlgorithm" is non-null, it runs some identity
checks using X509TrustManagerImpl, regardless of what custom TrustManager
was set by the end user. I also found this Stackoverflow question:
https://stackoverflow.com/questions/51244136/tomcat-websocket-disable-hostname-verification,
which led me to this hardcoded parameter in WsWebSocketContainer:
https://github.com/apache/tomcat/blob/db0c10ea25cc8984f72d700ea48f32aadc2fe2f4/java/org/apache/tomcat/websocket/WsWebSocketContainer.java#L928
.

So, it seems to me that while you can disable *certificate* verification by
setting a custom TrustManager, you cannot disable *hostname* verification.
Is that correct, or am I missing some other option or parameter?

Thanks,
Zoe

Re: Websockets: get Reference to @ServerEndpoint in a Servlet ?

[Mark Thomas]

On 30/06/2022 11:56, Jürgen Weber wrote:

Hi,

use case: HTML clients connect to @ServerEndpoint, some Servlet.GET
should send a message to connected HTML clients.

I found no other way to have the Servlet have a reference to the
ServerEndpoint than a hack with a static field, as in the Tomcat
sample.

https://github.com/apache/tomcat/blob/3e5ce3108e2684bc25013d9a84a7966a6dcd6e14/webapps/examples/WEB-INF/classes/websocket/drawboard/DrawboardContextListener.java

Is there indeed no better way?


Generally, no. You are going to need to do something along those lines.

Depending on the use case, it might be sufficient to have a single 
Endpoint instance. That would allow the use of instance fields rather 
than static fields. See section 3.1.78 of the WebSocket 2.1 
specification for a description of how to configure the use of a single 
endpoint instance.


Mark

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

Websockets: get Reference to @ServerEndpoint in a Servlet ?

[Jürgen Weber]

Hi,

use case: HTML clients connect to @ServerEndpoint, some Servlet.GET
should send a message to connected HTML clients.

I found no other way to have the Servlet have a reference to the
ServerEndpoint than a hack with a static field, as in the Tomcat
sample.

https://github.com/apache/tomcat/blob/3e5ce3108e2684bc25013d9a84a7966a6dcd6e14/webapps/examples/WEB-INF/classes/websocket/drawboard/DrawboardContextListener.java

Is there indeed no better way?


public class WSServlet extends HttpServlet

public static WebSocketRef webSocketRef;


@ServerEndpoint(value = "/broadcast")
public class BroadCastEndpoint
{

public BroadCastEndpoint()
{
WSServlet.webSocketRef = new WebSocketRef();
WSServlet.webSocketRef.broadCastEndpoint = this;

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

Re: Load balancing websockets

[Christopher Schultz]

Sridar,

On 7/28/21 20:16, Sridhar Rao wrote:

We are using the tomcat8.5 app nodes behind an Nginx Load Balancer.
Whenever the LB takes out an app node from the pool, "existing" WebSocket
connections are still staying with the app node. Also, if a new app node is
added to the pool, WS connections are not load balanced as they are
persistent. In general, wondering what are some of the mechanisms/tools are
employed to handle WebSocket load balancing issues.


Websocket is a connection-oriented protocol negotiated through a 
connectionless protocol (HTTP), and you end up with a persistent 
connection from client to server. Compare this to the (very!) old style 
of connecting a telephone call between two distant callers by making a 
series of physical connections such that you have one continuous circuit 
between the caller and the receiver. (That was before switching was 
introduced.)


Anyhow, once the connection has been established, what you describe is 
expected behavior: only HTTP can be load-balanced. Once the Websocket 
connection has been established, there is no way to "migrate" the 
connection to another node.


What you *can* do is terminate the connection and establish a new one, 
which will indeed be load-balanced as you expect.


Note that this may be awkward for your application.

One of the easiest possible things to do would be to implement a 
timed-termination of the connection on the client and/or the server so 
that Webocket connections never last more than e.g. 1 minute so your 
load-balancing becomes effective again.


Another possibility would be to think about why you are using Websocket 
in a way that would *require* load-balancing.


-chris

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

Load balancing websockets

[Sridhar Rao]

Hi All,

We are using the tomcat8.5 app nodes behind an Nginx Load Balancer.
Whenever the LB takes out an app node from the pool, "existing" WebSocket
connections are still staying with the app node. Also, if a new app node is
added to the pool, WS connections are not load balanced as they are
persistent. In general, wondering what are some of the mechanisms/tools are
employed to handle WebSocket load balancing issues.

Thanks,

Re: Tomcat Secure WebSockets clients - hostname verification

[Gary Sheppard]

On Wed, Oct 9, 2019, 18:11 Gary Sheppard wrote:

> On Tue, Jun 12, 2018 at 12:13 Mark Thomas wrote:
>
> >> It would be very useful to be able to configure this, so if you are
> >> going to patch the code, please make this configurable by the client.
> >> See HttpsURLConnection.setHostnameVerifier
> >>
> >> I think it's appropriate to simply match that API unless there are any
> >> objections.
> >
> > I'll see what I can do. The major constraint is that all this has to be
> > set via Tomcat specific user properties as there is no API for in the
> > Java WebSocket API.
>
> I realize I'm very late to the conversation, but did this ever get into
> the Tomcat WebSocket client, i.e. the ability to set a custom
> HostnameVerifier? Or did anyone come up with a nice workaround?
>

Actually I may have stumbled on it just now:

https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html

"For secure server end points, host name verification is enabled by
default. To bypass this verification (not recommended), it is necessary to
provide a custom SSLContext via the
org.apache.tomcat.websocket.SSL_CONTEXT user
property. The custom SSLContext must be configured with a custom
TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The
desired verification (or lack of verification) can then be controlled by
appropriate implementations of the individual abstract methods."

I will try this tomorrow and see how it goes.

—Gary

>

Re: Tomcat Secure WebSockets clients - hostname verification

[Gary Sheppard]

On Tue, Jun 12, 2018 at 12:13 Mark Thomas wrote:

>> It would be very useful to be able to configure this, so if you are
>> going to patch the code, please make this configurable by the client.
>> See HttpsURLConnection.setHostnameVerifier
>>
>> I think it's appropriate to simply match that API unless there are any
>> objections.
>
> I'll see what I can do. The major constraint is that all this has to be
> set via Tomcat specific user properties as there is no API for in the
> Java WebSocket API.

I realize I'm very late to the conversation, but did this ever get into the
Tomcat WebSocket client, i.e. the ability to set a custom HostnameVerifier?
Or did anyone come up with a nice workaround?

Thanks,
Gary

Re: Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Mark Thomas]

On 31/07/2019 04:37, Kirill Ilyukhin wrote:
> Hello Mark,
> 
> Please let me disagree with you. I have connected JVisualVM to Tomcat JVM,
> run the test with 10,000 connections, performed several explicit GCs and
> made a heap dump. All 10,000 WsSessions are in heap. They are referenced as
> following:

Sorry, I can't repeat this. I am using:

- the sample server code provided previously
- the client code provided previously
- the server.xml provided below
- Tomcat 8.5.44-dev (there are no relevant changes since 8.5.43)
- openjdk 1.8.0_212-b04
- linux

I have also tried to re-create the issue on OSX without success.

I have also tried to re-create the issue with 8.5.43 without success.

> this
>  <- wsSession - class:
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler
>   <- internalHttpUpgradeHandler - class:
> org.apache.coyote.http11.upgrade.UpgradeProcessorInternal
><- val - class: java.util.concurrent.ConcurrentHashMap$Node
> <- [12930] - class: java.util.concurrent.ConcurrentHashMap$Node[]
>  <- table - class: java.util.concurrent.ConcurrentHashMap
>   <- connections - class:
> org.apache.coyote.AbstractProtocol$ConnectionHandler
><- handler - class: org.apache.tomcat.util.net.NioEndpoint
> <- this$0 (Java frame) - class:
> org.apache.tomcat.util.net.NioEndpoint$Acceptor

That suggests connections aren't being closed properly. Various bugs
have been fixed in this area but all those fixes are present in 8.5.43.

> Do you think it might be Tomcat configuration dependent? Please see my
> server.xml below.

I think there is something about your environment that is triggering
this. Have you tried re-creating this with a completely clean (OS, Java,
Tomcat) install?

Mark

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

Re: Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Kirill Ilyukhin]

Hello Mark,

Please let me disagree with you. I have connected JVisualVM to Tomcat JVM,
run the test with 10,000 connections, performed several explicit GCs and
made a heap dump. All 10,000 WsSessions are in heap. They are referenced as
following:
this
 <- wsSession - class:
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler
  <- internalHttpUpgradeHandler - class:
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal
   <- val - class: java.util.concurrent.ConcurrentHashMap$Node
<- [12930] - class: java.util.concurrent.ConcurrentHashMap$Node[]
 <- table - class: java.util.concurrent.ConcurrentHashMap
  <- connections - class:
org.apache.coyote.AbstractProtocol$ConnectionHandler
   <- handler - class: org.apache.tomcat.util.net.NioEndpoint
<- this$0 (Java frame) - class:
org.apache.tomcat.util.net.NioEndpoint$Acceptor

Do you think it might be Tomcat configuration dependent? Please see my
server.xml below.



  
  
  
  
  
  

  
  



  

  
  

  

  


Thank you,
Kirill

On Tue, 30 Jul 2019 at 21:45, Mark Thomas  wrote:

> On 30/07/2019 05:48, Kirill Ilyukhin wrote:
> > Hello Mark,
> >
> > Please see the test case and Tomcat JVM heap dump screenshot attached.
> > For sake of simplicity I do Thread.sleep() in client code instead of
> > reading bytes from server.
>
> That test case does not demonstrate a memory leak in either Tomcat 9.0.x
> nor Tomcat 8.5.x.
>
> There are some WsSession instances in memory at the end of the test but
> they are unreachable - i.e. eligible for GC.
>
> Mark
>
>
> > Test configuration is the following:
> >
> > Server version:Apache Tomcat/8.5.3
> > Server built:  Jun 9 2016 11:16:29 UTC
> > Server number: 8.5.3.0
> > OS Name:   Mac OS X
> > OS Version:10.14.5
> > Architecture:  x86_64
> > JVM Version:   1.8.0_112-b16
> > JVM Vendor:Oracle Corporation
> > The APR based Apache Tomcat Native library which allows optimal
> > performance in production environments was not found on the
> > java.library.path: ...
> >
> > Thank you,
> > Kirill
> >
> > On Tue, 30 Jul 2019 at 02:15, Mark Thomas  > > wrote:
> >
> > On 26/07/2019 10:33, Kirill Ilyukhin wrote:
> > > Hello,
> > >
> > > When Tomcat receives WebSocket text message with invalid UTF-8, it
> > closes
> > > this connection with NOT_CONSISTENT reason. But after that some
> > objects
> > > (WsSession, UpgradeHandler, etc) stay in heap forever. They are
> > referenced
> > > from AbstractProtocol's connections map.
> > >
> > > This leak consistently happens with Tomcat 8.5.3 and 8.5.43, both
> > on Mac OS
> > > and Windows, with or without Tomcat native.
> > >
> > > I have created a very simple WebSocket Endpoint which does nothing
> > except
> > > logging its events and incoming messages, please see the code
> > below. Also
> > > you will need a WebSocket client which sends broken UTF-8 in text
> > message
> > > right after connecting to the server.
> >
> > I can't repeat this with either 9.0.x nor 8.5.x. I've repeated the
> steps
> > described above and checked the resulting state with a profiler. No
> > references are retained to WsSession objects nor WsHttpUpgradeHandler
> > objects.
> >
> > You'll need to provide the simplest possible test case (single class
> > client, simplest possible WAR) that demonstrates the issue.
> >
> > Mark
> >
> >
> > >
> > > Thank you,
> > > Kirill
> > >
> > > ---
> > > package com.example.wstest;
> > >
> > > import org.apache.log4j.Logger;
> > > import javax.websocket.*;
> > >
> > > public class WSEndpoint extends Endpoint {
> > > private static final Logger logger =
> > Logger.getLogger(WSEndpoint.class);
> > > private WSConnection connection;
> > >
> > > @Override
> > > public void onOpen(Session session, EndpointConfig config) {
> > > connection = new WSConnection(session);
> > > logger.info ("Opened WebSocket
> > session-" + session.getId());
> > > }
> > >
> > > @Override
> > > public void onClose(Session session, CloseReason closeReason) {
> > > logger.info ("Closed WebSocket
> > session-" + session.getId() + ",
> > > reason: " + closeReason.getCloseCode() + " (" +
> > > closeReason.getReasonPhrase() + ")");
> > > connection.destroy();
> > > connection = null;
> > > }
> > >
> > > @Override
> > > public void onError(Session session, Throwable throwable) {
> > > logger.info ("Error on WebSocket
> > session-" + session.getId(),
> > > throwable);
> > >   

Re: Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Mark Thomas]

On 30/07/2019 05:48, Kirill Ilyukhin wrote:
> Hello Mark,
> 
> Please see the test case and Tomcat JVM heap dump screenshot attached. 
> For sake of simplicity I do Thread.sleep() in client code instead of
> reading bytes from server.

That test case does not demonstrate a memory leak in either Tomcat 9.0.x
nor Tomcat 8.5.x.

There are some WsSession instances in memory at the end of the test but
they are unreachable - i.e. eligible for GC.

Mark


> Test configuration is the following:
> 
> Server version:        Apache Tomcat/8.5.3
> Server built:          Jun 9 2016 11:16:29 UTC
> Server number:         8.5.3.0
> OS Name:               Mac OS X
> OS Version:            10.14.5
> Architecture:          x86_64
> JVM Version:           1.8.0_112-b16
> JVM Vendor:            Oracle Corporation
> The APR based Apache Tomcat Native library which allows optimal
> performance in production environments was not found on the
> java.library.path: ...
> 
> Thank you,
> Kirill
> 
> On Tue, 30 Jul 2019 at 02:15, Mark Thomas  > wrote:
> 
> On 26/07/2019 10:33, Kirill Ilyukhin wrote:
> > Hello,
> >
> > When Tomcat receives WebSocket text message with invalid UTF-8, it
> closes
> > this connection with NOT_CONSISTENT reason. But after that some
> objects
> > (WsSession, UpgradeHandler, etc) stay in heap forever. They are
> referenced
> > from AbstractProtocol's connections map.
> >
> > This leak consistently happens with Tomcat 8.5.3 and 8.5.43, both
> on Mac OS
> > and Windows, with or without Tomcat native.
> >
> > I have created a very simple WebSocket Endpoint which does nothing
> except
> > logging its events and incoming messages, please see the code
> below. Also
> > you will need a WebSocket client which sends broken UTF-8 in text
> message
> > right after connecting to the server.
> 
> I can't repeat this with either 9.0.x nor 8.5.x. I've repeated the steps
> described above and checked the resulting state with a profiler. No
> references are retained to WsSession objects nor WsHttpUpgradeHandler
> objects.
> 
> You'll need to provide the simplest possible test case (single class
> client, simplest possible WAR) that demonstrates the issue.
> 
> Mark
> 
> 
> >
> > Thank you,
> > Kirill
> >
> > ---
> > package com.example.wstest;
> >
> > import org.apache.log4j.Logger;
> > import javax.websocket.*;
> >
> > public class WSEndpoint extends Endpoint {
> >     private static final Logger logger =
> Logger.getLogger(WSEndpoint.class);
> >     private WSConnection connection;
> >
> >     @Override
> >     public void onOpen(Session session, EndpointConfig config) {
> >         connection = new WSConnection(session);
> >         logger.info ("Opened WebSocket
> session-" + session.getId());
> >     }
> >
> >     @Override
> >     public void onClose(Session session, CloseReason closeReason) {
> >         logger.info ("Closed WebSocket
> session-" + session.getId() + ",
> > reason: " + closeReason.getCloseCode() + " (" +
> > closeReason.getReasonPhrase() + ")");
> >         connection.destroy();
> >         connection = null;
> >     }
> >
> >     @Override
> >     public void onError(Session session, Throwable throwable) {
> >         logger.info ("Error on WebSocket
> session-" + session.getId(),
> > throwable);
> >         connection.destroy();
> >         connection = null;
> >     }
> >
> >     static class WSConnection implements
> MessageHandler.Whole {
> >         private final Session session;
> >
> >         WSConnection(Session session) {
> >             this.session = session;
> >             session.addMessageHandler(this);
> >         }
> >
> >         public void destroy() {
> >             session.removeMessageHandler(this);
> >         }
> >
> >         @Override
> >         public void onMessage(String message) {
> >             logger.info ("Session-" +
> session.getId() + " onMessage(" +
> > message  +")");
> >         }
> >     }
> > }
> > ---
> >
> 
> 
> -
> 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: Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Kirill Ilyukhin]

Hello Mark,

Please see the test case and Tomcat JVM heap dump screenshot attached.
For sake of simplicity I do Thread.sleep() in client code instead of
reading bytes from server.
Test configuration is the following:

Server version:Apache Tomcat/8.5.3
Server built:  Jun 9 2016 11:16:29 UTC
Server number: 8.5.3.0
OS Name:   Mac OS X
OS Version:10.14.5
Architecture:  x86_64
JVM Version:   1.8.0_112-b16
JVM Vendor:Oracle Corporation
The APR based Apache Tomcat Native library which allows optimal performance
in production environments was not found on the java.library.path: ...

Thank you,
Kirill

On Tue, 30 Jul 2019 at 02:15, Mark Thomas  wrote:

> On 26/07/2019 10:33, Kirill Ilyukhin wrote:
> > Hello,
> >
> > When Tomcat receives WebSocket text message with invalid UTF-8, it closes
> > this connection with NOT_CONSISTENT reason. But after that some objects
> > (WsSession, UpgradeHandler, etc) stay in heap forever. They are
> referenced
> > from AbstractProtocol's connections map.
> >
> > This leak consistently happens with Tomcat 8.5.3 and 8.5.43, both on Mac
> OS
> > and Windows, with or without Tomcat native.
> >
> > I have created a very simple WebSocket Endpoint which does nothing except
> > logging its events and incoming messages, please see the code below. Also
> > you will need a WebSocket client which sends broken UTF-8 in text message
> > right after connecting to the server.
>
> I can't repeat this with either 9.0.x nor 8.5.x. I've repeated the steps
> described above and checked the resulting state with a profiler. No
> references are retained to WsSession objects nor WsHttpUpgradeHandler
> objects.
>
> You'll need to provide the simplest possible test case (single class
> client, simplest possible WAR) that demonstrates the issue.
>
> Mark
>
>
> >
> > Thank you,
> > Kirill
> >
> > ---
> > package com.example.wstest;
> >
> > import org.apache.log4j.Logger;
> > import javax.websocket.*;
> >
> > public class WSEndpoint extends Endpoint {
> > private static final Logger logger =
> Logger.getLogger(WSEndpoint.class);
> > private WSConnection connection;
> >
> > @Override
> > public void onOpen(Session session, EndpointConfig config) {
> > connection = new WSConnection(session);
> > logger.info("Opened WebSocket session-" + session.getId());
> > }
> >
> > @Override
> > public void onClose(Session session, CloseReason closeReason) {
> > logger.info("Closed WebSocket session-" + session.getId() + ",
> > reason: " + closeReason.getCloseCode() + " (" +
> > closeReason.getReasonPhrase() + ")");
> > connection.destroy();
> > connection = null;
> > }
> >
> > @Override
> > public void onError(Session session, Throwable throwable) {
> > logger.info("Error on WebSocket session-" + session.getId(),
> > throwable);
> > connection.destroy();
> > connection = null;
> > }
> >
> > static class WSConnection implements MessageHandler.Whole {
> > private final Session session;
> >
> > WSConnection(Session session) {
> > this.session = session;
> > session.addMessageHandler(this);
> > }
> >
> > public void destroy() {
> > session.removeMessageHandler(this);
> > }
> >
> > @Override
> > public void onMessage(String message) {
> > logger.info("Session-" + session.getId() + " onMessage(" +
> > message  +")");
> > }
> > }
> > }
> > ---
> >
>
>
> -
> 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: Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Mark Thomas]

On 26/07/2019 10:33, Kirill Ilyukhin wrote:
> Hello,
> 
> When Tomcat receives WebSocket text message with invalid UTF-8, it closes
> this connection with NOT_CONSISTENT reason. But after that some objects
> (WsSession, UpgradeHandler, etc) stay in heap forever. They are referenced
> from AbstractProtocol's connections map.
> 
> This leak consistently happens with Tomcat 8.5.3 and 8.5.43, both on Mac OS
> and Windows, with or without Tomcat native.
> 
> I have created a very simple WebSocket Endpoint which does nothing except
> logging its events and incoming messages, please see the code below. Also
> you will need a WebSocket client which sends broken UTF-8 in text message
> right after connecting to the server.

I can't repeat this with either 9.0.x nor 8.5.x. I've repeated the steps
described above and checked the resulting state with a profiler. No
references are retained to WsSession objects nor WsHttpUpgradeHandler
objects.

You'll need to provide the simplest possible test case (single class
client, simplest possible WAR) that demonstrates the issue.

Mark


> 
> Thank you,
> Kirill
> 
> ---
> package com.example.wstest;
> 
> import org.apache.log4j.Logger;
> import javax.websocket.*;
> 
> public class WSEndpoint extends Endpoint {
> private static final Logger logger = Logger.getLogger(WSEndpoint.class);
> private WSConnection connection;
> 
> @Override
> public void onOpen(Session session, EndpointConfig config) {
> connection = new WSConnection(session);
> logger.info("Opened WebSocket session-" + session.getId());
> }
> 
> @Override
> public void onClose(Session session, CloseReason closeReason) {
> logger.info("Closed WebSocket session-" + session.getId() + ",
> reason: " + closeReason.getCloseCode() + " (" +
> closeReason.getReasonPhrase() + ")");
> connection.destroy();
> connection = null;
> }
> 
> @Override
> public void onError(Session session, Throwable throwable) {
> logger.info("Error on WebSocket session-" + session.getId(),
> throwable);
> connection.destroy();
> connection = null;
> }
> 
> static class WSConnection implements MessageHandler.Whole {
> private final Session session;
> 
> WSConnection(Session session) {
> this.session = session;
> session.addMessageHandler(this);
> }
> 
> public void destroy() {
> session.removeMessageHandler(this);
> }
> 
> @Override
> public void onMessage(String message) {
> logger.info("Session-" + session.getId() + " onMessage(" +
> message  +")");
> }
> }
> }
> ---
> 


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

Resource leak for WebSockets closed with NOT_CONSISTENT reason

[Kirill Ilyukhin]

Hello,

When Tomcat receives WebSocket text message with invalid UTF-8, it closes
this connection with NOT_CONSISTENT reason. But after that some objects
(WsSession, UpgradeHandler, etc) stay in heap forever. They are referenced
from AbstractProtocol's connections map.

This leak consistently happens with Tomcat 8.5.3 and 8.5.43, both on Mac OS
and Windows, with or without Tomcat native.

I have created a very simple WebSocket Endpoint which does nothing except
logging its events and incoming messages, please see the code below. Also
you will need a WebSocket client which sends broken UTF-8 in text message
right after connecting to the server.

Thank you,
Kirill

---
package com.example.wstest;

import org.apache.log4j.Logger;
import javax.websocket.*;

public class WSEndpoint extends Endpoint {
private static final Logger logger = Logger.getLogger(WSEndpoint.class);
private WSConnection connection;

@Override
public void onOpen(Session session, EndpointConfig config) {
connection = new WSConnection(session);
logger.info("Opened WebSocket session-" + session.getId());
}

@Override
public void onClose(Session session, CloseReason closeReason) {
logger.info("Closed WebSocket session-" + session.getId() + ",
reason: " + closeReason.getCloseCode() + " (" +
closeReason.getReasonPhrase() + ")");
connection.destroy();
connection = null;
}

@Override
public void onError(Session session, Throwable throwable) {
logger.info("Error on WebSocket session-" + session.getId(),
throwable);
connection.destroy();
connection = null;
}

static class WSConnection implements MessageHandler.Whole {
private final Session session;

WSConnection(Session session) {
this.session = session;
session.addMessageHandler(this);
}

public void destroy() {
session.removeMessageHandler(this);
}

@Override
public void onMessage(String message) {
logger.info("Session-" + session.getId() + " onMessage(" +
message  +")");
}
}
}
---

Re: Using custom Configurator with WebSockets

[Christopher Dodunski]

Your idea of wrapping the interface returned by the registry was a stroke
of brilliance!  And I'm pleased to say it was successful.

I'm now working to resolve another small hiccup.  The IoC registry can be
configured to provide the service as either a singleton or a new instance
for each new thread.  I chose the latter.  Socket connections are
established without problem, but if Tomcat subsequently calls @OnError
and/or @OnClose on a connection, the IoC registry provides a new instance
(not good).  This suggests that the subsequent method call on the socket
comes via a new thread.  So bit of a mismatch there between sessions and
threads.

I may have to move to a singleton service, meaning no longer being able to
persist connection endpoints to a static map with a simple:
connections.put(this).

Thanks again,

Chris.


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

Re: Using custom Configurator with WebSockets

[Mark Thomas]

Hmm.

Looking at this some more I'm not sure this is going to work.

HarbourServerEndpoint needs to extend javax.websocket.Endpoint which it
can't do as an interface.

I think you are going to have to wrap the instance returned by the
registry. In which case you can probably go back to using POJO.

So you'd have something like (I'm typing directly in email so the
chances of this compiling first time are slim):

@ServerEndpoint(...)
HarbourServerEndpointWrapper

private HarbourServerEndpoint inner;

public HarbourServerEndpointWrapper() {
inner = RegistryProxy.getService(HarbourServerEndpoint.class);
}

@OnOpen
void onOpen(Session session, EndpointConfig config) {
inner.onOpen(Session session, EndpointConfig config);
}

@OnMessage
void onMessageMessage(Session session, Message message) {
inner.onMessageMessage(Session session, Message message);
}

@OnClose
void onClose(Session session, CloseReason reason) {
inner.onClose(Session session, CloseReason reason);
}

@OnError
void onError(Session session, Throwable throwable) {
inner.onError(Session session, Throwable throwable);
}
}

Mark

On 26/04/2019 11:07, Christopher Dodunski wrote:
> So I've converted the server endpoint from annotation-based to
> programmatic, to get around the constraint of the @ServerEndpoint
> annotation having to decorate a concrete class.  The elements of this
> annotation now occupy an implementation of ServerApplicationConfig:
> 
> 
> public class HarbourServerApplicationConfig implements
> ServerApplicationConfig {
> 
> ...
> 
> @Override
> public Set getEndpointConfigs(Set extends Endpoint>> endpointClasses) {
> Set result = new HashSet<>();
> ServerEndpointConfig configuration =
> ServerEndpointConfig.Builder.create(HarbourServerEndpoint.class,
> "/websocket/{port-name}/{username}")
> .configurator(configurator)
> .encoders(encoders)
> .decoders(decoders)
> .build();
> result.add(configuration);
> 
> return result;
> }
> }
> 
> 
> All works fine when the Builder.create() parameter is a concrete endpoint
> class, but not if an interface (the goal is having Tomcat accept as
> endpoint instances IoC proxy objects cast back to their interface).
> 
> The error message suggests that Tomcat is treating this class as concrete.
> 
> 
> 26-Apr-2019 20:00:40.605 SEVERE [ajp-nio-127.0.0.1-8009-exec-197]
> org.apache.catalina.core.ContainerBase.addChildInternal
> ContainerBase.addChild: start:
>  org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/harbour]]
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
> ...
> Caused by: java.lang.NullPointerException
> at
> org.apache.tomcat.websocket.pojo.PojoMethodMapping.(PojoMethodMapping.java:85)
> at
> org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:147)
> at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:116)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5245)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 46 more
> 
> 
> Lastly, below is the interface itself (my programmatic endpoint implements
> this).
> 
> 
> public interface HarbourServerEndpoint {
> 
> void onOpen(Session session, EndpointConfig config);
> 
> void onMessageMessage(Session session, Message message);
> 
> void onClose(Session session, CloseReason reason);
> 
> void onError(Session session, Throwable throwable);
> }
> 
> 
> Unfortunately online examples of programmatic endpoints are sparse, and
> the few to be found very basic.  So am quite reliant on those familiar
> with the WebSocket library, and Tomcat's application of it.
> 
> Kind regards,
> 
> Chris.
> 
> 
> -
> 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: Using custom Configurator with WebSockets

[Christopher Dodunski]

So I've converted the server endpoint from annotation-based to
programmatic, to get around the constraint of the @ServerEndpoint
annotation having to decorate a concrete class.  The elements of this
annotation now occupy an implementation of ServerApplicationConfig:


public class HarbourServerApplicationConfig implements
ServerApplicationConfig {

...

@Override
public Set getEndpointConfigs(Set> endpointClasses) {
Set result = new HashSet<>();
ServerEndpointConfig configuration =
ServerEndpointConfig.Builder.create(HarbourServerEndpoint.class,
"/websocket/{port-name}/{username}")
.configurator(configurator)
.encoders(encoders)
.decoders(decoders)
.build();
result.add(configuration);

return result;
}
}


All works fine when the Builder.create() parameter is a concrete endpoint
class, but not if an interface (the goal is having Tomcat accept as
endpoint instances IoC proxy objects cast back to their interface).

The error message suggests that Tomcat is treating this class as concrete.


26-Apr-2019 20:00:40.605 SEVERE [ajp-nio-127.0.0.1-8009-exec-197]
org.apache.catalina.core.ContainerBase.addChildInternal
ContainerBase.addChild: start:
 org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/harbour]]
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
...
Caused by: java.lang.NullPointerException
at
org.apache.tomcat.websocket.pojo.PojoMethodMapping.(PojoMethodMapping.java:85)
at
org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:147)
at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:116)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5245)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 46 more


Lastly, below is the interface itself (my programmatic endpoint implements
this).


public interface HarbourServerEndpoint {

void onOpen(Session session, EndpointConfig config);

void onMessageMessage(Session session, Message message);

void onClose(Session session, CloseReason reason);

void onError(Session session, Throwable throwable);
}


Unfortunately online examples of programmatic endpoints are sparse, and
the few to be found very basic.  So am quite reliant on those familiar
with the WebSocket library, and Tomcat's application of it.

Kind regards,

Chris.


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

Re: Using custom Configurator with WebSockets

[Christopher Dodunski]

Thanks Mark, you've made it clear that annotating the interface is not an
option.

Converting my server endpoint from annotation based to programmatic is not
a problem, nor is implementing ServerApplicationConfig to configure what
were previously @ServerEndpoint elements: value, encoders, decoders,
configurator.

What is not clear is how this will solve the problem of Tomcat not
accepting an interface as an endpoint.  Afterall, the programmatic
approach still employs Configurator.getEndpointInstance(), and this is
where I came unstuck with annotations.

Below is the beginnings of my custom ServerApplicationConfig implementation.



public class CustomServerAppConfig implements ServerApplicationConfig {

@Override
public Set getEndpointConfigs(Set> endpointClasses) {
Set result = new HashSet<>();
for (Class epClass : endpointClasses) {
if (epClass.equals(MyEndpointInterface.class)) {
ServerEndpointConfig sec =
ServerEndpointConfig.Builder.create(epClass,
"/websocket").build();
result.add(sec);
}
}
return result;
}

@Override
public Set> getAnnotatedEndpointClasses(Set> scanned) {
return Collections.emptySet();
}
}


Regards,

Chris.


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

Re: Using custom Configurator with WebSockets

[Mark Thomas]

On 24/04/2019 07:16, Christopher Dodunski wrote:
> Hi Mark,
> 
> Looking at the Tapestry-IoC Registry code I notice that although it
> constructs a (plastic) service proxy object, it does cast it to its
> associated interface before making it available from the registry's
> getService() method.  So if I move the WebSocket annotations to my
> interface as previously thought, Tomcat should be getting back from the
> registry what it expects: an instance of the interface annotated with
> @ServerEndpoint.
> 
> Just wondering how this sits with your understanding of the WebSocket
> library.

It won't work. From the Java WebSockets specification:

4.1
@ServerEndpoint
This class level annotation signifies that the Java class it decorates
must be deployed by the implementation as a websocket server endpoint
and made available in the URI-space of the websocket implementation.
*The class must be public, concrete, and have a public no-args constructor.*

(my emphasis)

I don't see a way to do this with annotations. You are going to need to
do it programmatically.

The WebSocket examples that ship with Tomcat include several endpoints
configured this way. There are further examples in the unit tests.

Mark

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

Re: Using custom Configurator with WebSockets

[Christopher Dodunski]

Hi Mark,

Looking at the Tapestry-IoC Registry code I notice that although it
constructs a (plastic) service proxy object, it does cast it to its
associated interface before making it available from the registry's
getService() method.  So if I move the WebSocket annotations to my
interface as previously thought, Tomcat should be getting back from the
registry what it expects: an instance of the interface annotated with
@ServerEndpoint.

Just wondering how this sits with your understanding of the WebSocket
library.

Regards,

Chris.


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

Re: Using custom Configurator with WebSockets

[Christopher Dodunski]

Based on what you wrote regarding WebSocket annotations not following Java
inheritance, I imagine the below wouldn't work either.


public class MyServerEndpointConfig extends ServerEndpointConfig {

@Override
public Class getEndpointClass() {
return MyServiceInterface.class;
}
}




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

Re: Using custom Configurator with WebSockets

[Christopher Dodunski]

> The custom Configurator looks fine. The problem is with trying to do
> this with a POJO endpoint. There is an underlying assumption that - for
> a POJO endpoint - the endpoints will will instances of the POJO class.
> This doesn't seem to hold in your case so hence it breaks.
>
> The WebSocket spec explicitly states that WebSocket annotations do not
> follow Java inheritance so moving the annotation to the interface is not
> an option.
>
> I think you are going to have to build your ServerEndpointConfig
> programmatically so you can specify the correct endpoint class.
>
> Mark

Thank you very much Mark for explaining.  After examining the Tapestry-IoC
a little closer, I discovered that what is being returned from the
Registry is in fact a 'service proxy object'.  It implements the same
service interface as my implementation class, but it is NOT an instance of
my implementation class.

I was thinking to shift my WebSocket annotations from the service
implementation to the service interface, but you write that this won't
work either.

So I searched the net and found a number of examples of using build() to
define an endpoint configuration.  Do you happen to have an example where
the objective was the same - or very similar to - my own?  I guess the
goal is in having Tomcat accept a service proxy object that merely
implements a given service interface, yes?

Quoting from the Tapestry-IoC documentation:

"Services consist of two main parts: a service interface and a service
implementation. The service interface is how the service will be
represented throughout the rest of the registry. Since what gets passed
around is normally a proxy, you can't expect to cast a service object down
to the implementation class (you'll see a ClassCastException instead). In
other words, you should be careful to ensure that your service interface
is complete, since Tapestry IoC effectively walls you off from back doors
such as casts."

Regards,

Chris.


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

Re: Using custom Configurator with WebSockets

[Mark Thomas]

On 17/04/2019 22:58, Christopher Dodunski wrote:
> Hello,
> 
> Just a quick question with regard to extending
> ServerEndpointConfig.Configurator to override Tomcat's default action of
> instantiating the POJO class annotated with @ServerEndpoint on receiving a
> WebSocket request.  My reason for doing this is that my endpoint class
> depends on IoC dependency injection, and therefore needs to be got from
> the registry to have its dependencies in place.
> 
> My Configurator method:
> 
> 
> @Override
> public  T getEndpointInstance(Class endpointClass) throws
> InstantiationException {
> return
> endpointClass.cast(RegistryProxy.getService(HarbourServerEndpoint.class));
> }
> 
> 
> The @ServerEndpoint annotation is placed on on my
> HarbourServerEndpointImpl POJO class, not the interface that it
> implements.  Based on the below runtime catalina.out error message the
> problem appears to be that the registry is returning HarbourServerEndpoint
> whereas Tomcat is expecting an instance of HarbourServerEndpointImpl?
> 
> I'm hoping someone can please explain what is going wrong with my custom
> Configurator.

The custom Configurator looks fine. The problem is with trying to do
this with a POJO endpoint. There is an underlying assumption that - for
a POJO endpoint - the endpoints will will instances of the POJO class.
This doesn't seem to hold in your case so hence it breaks.

The WebSocket spec explicitly states that WebSocket annotations do not
follow Java inheritance so moving the annotation to the interface is not
an option.

I think you are going to have to build your ServerEndpointConfig
programmatically so you can specify the correct endpoint class.

Mark


> 
> 
> 15-Apr-2019 12:45:28.488 SEVERE [http-nio-8080-exec-915]
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading
> request, ignored
>  java.lang.ClassCastException: Cannot cast
> $HarbourServerEndpoint_39c9cc24eb8b2a to
> com.optomus.harbour.services.HarbourServerEndpointImpl
> at java.lang.Class.cast(Class.java:3369)
> at
> com.optomus.harbour.services.HarbourServerEndpointConfigurator.getEndpointInstance(HarbourServerEndpointConfigurator.java:17)
> at
> org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:44)
> at
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:133)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:846)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> 
> 
> Finally, with no casting at all, the compiler gives the error:
> 
> Error:(17, 40) java: incompatible types: inference variable T has
> incompatible bounds
> equality constraints:
> com.optomus.harbour.services.HarbourServerEndpoint
> upper bounds: T,java.lang.Object
> 
> 
> -
> 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

Using custom Configurator with WebSockets

[Christopher Dodunski]

Hello,

Just a quick question with regard to extending
ServerEndpointConfig.Configurator to override Tomcat's default action of
instantiating the POJO class annotated with @ServerEndpoint on receiving a
WebSocket request.  My reason for doing this is that my endpoint class
depends on IoC dependency injection, and therefore needs to be got from
the registry to have its dependencies in place.

My Configurator method:


@Override
public  T getEndpointInstance(Class endpointClass) throws
InstantiationException {
return
endpointClass.cast(RegistryProxy.getService(HarbourServerEndpoint.class));
}


The @ServerEndpoint annotation is placed on on my
HarbourServerEndpointImpl POJO class, not the interface that it
implements.  Based on the below runtime catalina.out error message the
problem appears to be that the registry is returning HarbourServerEndpoint
whereas Tomcat is expecting an instance of HarbourServerEndpointImpl?

I'm hoping someone can please explain what is going wrong with my custom
Configurator.


15-Apr-2019 12:45:28.488 SEVERE [http-nio-8080-exec-915]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading
request, ignored
 java.lang.ClassCastException: Cannot cast
$HarbourServerEndpoint_39c9cc24eb8b2a to
com.optomus.harbour.services.HarbourServerEndpointImpl
at java.lang.Class.cast(Class.java:3369)
at
com.optomus.harbour.services.HarbourServerEndpointConfigurator.getEndpointInstance(HarbourServerEndpointConfigurator.java:17)
at
org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:44)
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:133)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:846)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)


Finally, with no casting at all, the compiler gives the error:

Error:(17, 40) java: incompatible types: inference variable T has
incompatible bounds
equality constraints:
com.optomus.harbour.services.HarbourServerEndpoint
upper bounds: T,java.lang.Object


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

Re: Using WebSockets with a Tapestry WebApp running on Tomcat

[Christopher Dodunski]

Just to clarify, both services being injected the IoC way are developed by
me as part of the core program, so nothing sinister to be concerned about.

What would be useful to know is whether Tomcat instantiates classes
annotated with @ServerEndpoint inside or outside of the context of the WAR
app deployed on Tomcat.  If outside, probably this means that any endpoint
class (static) field values are not shared across ALL instances of the
endpoint (the Tapestry service registry also instantiates the endpoint as
a service, necessary for pushing messages out, such as with bulk
broadcasting).

Chris.


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

Re: Using WebSockets with a Tapestry WebApp running on Tomcat

[Christopher Dodunski]

Hi John,

The server-side endpoint is itself implemented as a Tapestry 'service',
allowing it to be injected into other application classes for pushing
messages out to connected clients.  Whereas the service injected into the
endpoint class itself allows the endpoint to query this service when a
client first connects, then send the client some data in the form of a
message to be displayed on the client's UI.

The whole point of the mutual injection between these two services (the
WebSocket being one) is to allow two way communication - push and pull.

Regards,

Chris.


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

Re: Using WebSockets with a Tapestry WebApp running on Tomcat

[John Dale]

IoC - *shudders*

Can't this be used to "inject" mass surveillance into J2E apps?  It
was curiously missing in the bullet items down the home page of
tapestry.  :p

So, you're expecting to inject dependencies into components
instantiated on a websocket?

By "the rest of the application" below, are you referring to
application code that's in tapestry, early in the chain of execution,
or code that is on/behind your websocket?

So, you're looking for some feature in tapestry that would inject some
kind of remoteable dependencies into/onto your websocket?

This is an interesting question to me .. it to ok me about 10 years,
but I created substitutes for both tapestry and HBN/Cayenne.  I found
that all the source code I needed to deploy ORM/MVC/JSON/HTML5 was
300KB.  I like being able to step through JavaScript, then step
through Java for debugging without having to negotiate etherial stubs
to far off services.

Looking forward to hearing about the resources you're trying to have
injected into your code.

Have a good one,

John
DB2DOM.COM


On 4/8/19, Christopher Dodunski  wrote:
> Hi team,
>
> I have developed a web application using the Apache Tapestry framework and
> deployed on Apache Tomcat.  The application also supports WebSocket
> connections with desktop clent applications.  Following the advice of the
> Tapestry community, I included the server-side endpoint within the
> Tapestry based application, but added the below declaration to the
> AppModule configuration, which basically instructs Tapestry to ignore any
> requests to the endpoint URI, leaving Tomcat to handle the request
> instead.
>
> public static void contributeIgnoredPathsFilter(Configuration
> configuration) {
> configuration.add("/websocket/.*");
> }
>
> The problem is that, as with any IoC based application, my WebSocket
> endpoint relies on dependency injection to interact with the rest of the
> application (ie. injected services).  And it seems, given that Tomcat is
> left to handle WebSocket connections independent of the Tapestry
> application, endpoints get instantiated but without the injected
> dependencies.  So, of course, a null pointer exception occurs once the
> endpoint attempts to invoke a dependency method.
>
> Moreover, presumably Tomcat is instantiating endpoints outside of the
> Tapestry realm, meaning that any class (static) field values are not
> shared across endpoints instantiated by Tapestry itself.
>
> Obviously leaving Tomcat to handle these WebSocket connections independent
> of the Tapestry application isn't working.  Is there a common solution to
> what I imagine is a pretty common scenario?  I'm not aware of how to have
> Tomcat connect to an endpoint instance already instantiated within the
> Tapestry application (one potential solution).
>
> Thanks & regards,
>
> Chris.
>
>
> -
> 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

Using WebSockets with a Tapestry WebApp running on Tomcat

[Christopher Dodunski]

Hi team,

I have developed a web application using the Apache Tapestry framework and
deployed on Apache Tomcat.  The application also supports WebSocket
connections with desktop clent applications.  Following the advice of the
Tapestry community, I included the server-side endpoint within the
Tapestry based application, but added the below declaration to the
AppModule configuration, which basically instructs Tapestry to ignore any
requests to the endpoint URI, leaving Tomcat to handle the request
instead.

public static void contributeIgnoredPathsFilter(Configuration
configuration) {
configuration.add("/websocket/.*");
}

The problem is that, as with any IoC based application, my WebSocket
endpoint relies on dependency injection to interact with the rest of the
application (ie. injected services).  And it seems, given that Tomcat is
left to handle WebSocket connections independent of the Tapestry
application, endpoints get instantiated but without the injected
dependencies.  So, of course, a null pointer exception occurs once the
endpoint attempts to invoke a dependency method.

Moreover, presumably Tomcat is instantiating endpoints outside of the
Tapestry realm, meaning that any class (static) field values are not
shared across endpoints instantiated by Tapestry itself.

Obviously leaving Tomcat to handle these WebSocket connections independent
of the Tapestry application isn't working.  Is there a common solution to
what I imagine is a pretty common scenario?  I'm not aware of how to have
Tomcat connect to an endpoint instance already instantiated within the
Tapestry application (one potential solution).

Thanks & regards,

Chris.


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

Re: HTTP2 with WebSockets

[Mark Thomas]

On 07/02/2019 00:31, Jesse Schulman wrote:
> Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> connector?  I have tried configuring it myself and looked for examples
> without success.

This works out of the box.

I have confirmed the behaviour with my local build of 9.0.x but nothing
has changed in this area for a number of releases.

First you need an HTTP/2 capable connector. That means:

Tomcat 8.5.x or Tomcat 9.0.x

NIO or NIO2 + JSSE + Java 9 or later
or
APR/Native
or
NIO or NIO2 + OpenSSL (via Tomcat Native)

If no explicit Java version is mentioned then any supported version of
Java for the version of Tomcat being used is fine.

Configure TLS.

Browse to http://localhost:8443

Observe in browser that HTTP/2 is used

Navigate to https://localhost:8443/examples/websocket/snake.xhtml and
you'll see HTTP/2 being used for the static content and wss (not over
HTTP/2) being used for the WebSocket traffic.

All over the single TLS enabled connector listening on port 8443.

Mark

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

Re: HTTP2 with WebSockets

[Jesse Schulman]

I could add a second port but then I’d have to change how the load balancer
works to add even more magic there than I already have... not sure http2 is
worth that effort.
On Wed, Feb 6, 2019 at 6:54 PM John Larsen  wrote:

> I am interested in this too. Basically we've had to set another port in
> which the app can access tomcat for websockets directly. We've not been
> able to get this to work over httpd.
> John
>
>
> On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman 
> wrote:
>
> > Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> > connector?  I have tried configuring it myself and looked for examples
> > without success.
> >
> > Thanks!
> > Jesse
> >
>

Re: HTTP2 with WebSockets

[John Larsen]

I am interested in this too. Basically we've had to set another port in
which the app can access tomcat for websockets directly. We've not been
able to get this to work over httpd.
John


On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman  wrote:

> Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> connector?  I have tried configuring it myself and looked for examples
> without success.
>
> Thanks!
> Jesse
>

HTTP2 with WebSockets

[Jesse Schulman]

Is it possible for tomcat to run with HTTP2 and WebSockets on the same
connector?  I have tried configuring it myself and looked for examples
without success.

Thanks!
Jesse

Re: WebSockets and JSPs

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shawn,

On 10/16/18 00:00, Shawn Heisey wrote:
> On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
>> I have several webapps that do a significant amount of recursive
>> loads of snippits of HTML utilizing XHR/http/ajax requests. These
>> apps are all debugged and in production.   The server has no
>> problem whatsoever in keeping up with the multiple concurrent
>> requests.  However, the open-connection limits on the browsers
>> that block more than 6 concurrent connections to a server is
>> killing me in performance.
> 
> I know pretty much nothing about the things you asked about after
> this paragraph.  But I do know about one thing that might help you
> -- HTTP/2.  It can execute many HTTP requests simultaneously over a
> single TCP connection.

+1

h2 will improve your performance with basically zero other changes to
your environment or to your application.

> I really have no idea how to enable HTTP/2 in Tomcat, but I know
> that it can be done if you have a new enough version.

It's configured by default in Tomcat 8.5.x and later. Basically, you
just have to add this inside your  element in
conf/server.xml if it isn't already there:

  

> Another possibility is to put your web services behind a load
> balancer that supports HTTP/2 on the front end.  Haproxy is one
> that I am aware of with that support.

Basically everyone[1] supports h2. Hmm... no Squid. :(

Jerry, switching to Websocket basically requires you to rewrite your
application using a different protocol. I don't think you really want
to do that.

- -chris

[1] https://en.wikipedia.org/wiki/HTTP/2#Server_software
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIoG4ACgkQHPApP6U8
pFgq8g//bU2tji+UM7j68ZRQIUazDTVlaQePwNLw5JicBuF+kkadBiSsKjp9qytO
P18JiuBTHm6AJZ/PrCvPrG4ceJbT7QzdMD1daj6hD5MkdOyPSiK0QTuqV5r+V7Dm
cjWGZ2F8WRIKN8w9BX3XNPZ3aLyf4pAd68EGow9R4Cm9FoMJ17kT1a1ALs/Iw0pX
5Ditcsl1SbnSyk+CxwgehLRkc7mub0c7Wk7bI6uYCzZrZt2ddNTmNON2Eqgzd+UB
R+6NoOpIiQV/mvP8jFaqBy+OcVIzbuzM/otBzkmgbNDimTrLsT790vOcDLD3BxtB
sZCVk1aC+7wO1Elq+104l/E/bFCPn8bFDspZdMpvp/wxrt80Co36Nw/4Jkg7QoGn
h1l8JI8R/bt5/jOQhcqQH2/4peilP0Zs6ASTB+U0tV0M6J6n/qDLjqo68ueMzgmN
Bo4cYATzO92G55T0WuGlQOynlPhrVS2s4u2mTVuaeMc8m863VdMiGhQh2anEqpJN
MumeH4JKFSsj78lzjWOenjE9/N0Gm00eeO1O0hYsnIOEyftv7osaXxBO0gJoKFHV
ZF1SkX7ogHfutt8Yzga7I6VK8184rt7EYohl6zf7QU4mdQIkVKBHQrlKRxddqIoQ
HIDmUOUPMuiq6V0i0E4QDxpvnG+1Ax1DvRrj20BJ1DuwII0odZY=
=FDC4
-END PGP SIGNATURE-

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

Re: WebSockets and JSPs

[Shawn Heisey]

On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
I have several webapps that do a significant amount of recursive loads 
of snippits of HTML utilizing XHR/http/ajax requests. These apps are 
all debugged and in production.   The server has no problem whatsoever 
in keeping up with the multiple concurrent requests.  However, the 
open-connection limits on the browsers that block more than 6 
concurrent connections to a server is killing me in performance.


I know pretty much nothing about the things you asked about after this 
paragraph.  But I do know about one thing that might help you -- 
HTTP/2.  It can execute many HTTP requests simultaneously over a single 
TCP connection.


Here's a demo:

https://http2.akamai.com/demo

I really have no idea how to enable HTTP/2 in Tomcat, but I know that it 
can be done if you have a new enough version. Browsers with HTTP/2 
support should automatically multiplex requests to the same server over 
fewer connections.


Another possibility is to put your web services behind a load balancer 
that supports HTTP/2 on the front end.  Haproxy is one that I am aware 
of with that support.


HTTP/2 promises to obsolete many of the development and software tricks 
used in the past for improving web performance. Designing applications 
for performance has typically involved combining code into fewer files 
instead of aspiring to a highly modular application.  With HTTP/2, you 
can split things up without killing performance.


If anything I have said above is wrong, I would appreciate the community 
informing me about my errors.


Thanks,
Shawn


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

WebSockets and JSPs

[Jerry Malcolm]

I have several webapps that do a significant amount of recursive loads 
of snippits of HTML utilizing XHR/http/ajax requests. These apps are all 
debugged and in production.   The server has no problem whatsoever in 
keeping up with the multiple concurrent requests.  However, the 
open-connection limits on the browsers that block more than 6 concurrent 
connections to a server is killing me in performance.


I've been looking into WebSockets which I understand does not incur the 
wrath of the browsers when I have a need for more than 6 concurrent 
connections.   I have no problem making a move to WebSockets if that 
will indeed help performance.  However, I have literally many hundreds 
of JSPs that are coded, tested, and working.  So I'd like to minimize 
the rip-up to the JSPs.


I've googled around trying to find answers about how (if) I can invoke 
JSPs via WebSockets.  From what I can tell, it appears it's possible.  
But no straightforward explanation.   A WebSocket servlet extends 
"WebSocketServlet", correct?  But JSPs extend HTTPServlet, at least by 
default, correct.  So that seems like an fairly big immediate problem.


Do I need to do some gyrations like writing a WebSocket router servlet 
object that turns around and creates/invokes a normal http call to 
invoke the desired JSP?  (BTW... I don't need any of the bi-directional 
capabilities of WebSockets currently simply an "http emulator" 
functionality for now).


I guess I could get multiple IP addresses for the server and set up 
multiple secondary domain names to 'fool' the browsers into thinking the 
requests aren't all going to the same server thereby getting 6 requests 
per 'server'.  But at best that's a total hack, and not an inviting 
solution.


Any other suggestions (short of changing up the architecture to no 
longer require multiple concurrent loads)  will be welcomed. Likewise, 
and corrections to any errant assumptions I have made so far are also 
welcome.


Thx.

Jerry


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

Re: Tomcat Secure WebSockets clients - hostname verification

[tomcat]

Thanks, Remy and Chris, for providing this clarification.

On 12.06.2018 20:34, Rémy Maucherat wrote:

On Tue, Jun 12, 2018 at 7:05 PM André Warnier (tomcat) 
wrote:


This is a bit OT, but I have a question since the beginning of this thread
:
Is Tomcat really supposed to provide a websocket *client* API ?



Yes, the client API is part of the websockets EE specification. Initially,
Tomcat had just enough to implement the requirements of the specification,
so it was unusable in practice (users were supposed to use another client,
such as Tyrus which is now donated to Jakarta - feels nice to talk again
about "Sun" donating software to Jakarta :D ). Gradually, missing items are
implemented (as users didn't understand they really had to use something
else and using the Tomcat client was not mandatory, it seems), but since
this is not part of the specification, the config is all proprietary.

Rémy




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

Re: Tomcat Secure WebSockets clients - hostname verification

[Rémy Maucherat]

On Tue, Jun 12, 2018 at 7:05 PM André Warnier (tomcat) 
wrote:

> This is a bit OT, but I have a question since the beginning of this thread
> :
> Is Tomcat really supposed to provide a websocket *client* API ?
>

Yes, the client API is part of the websockets EE specification. Initially,
Tomcat had just enough to implement the requirements of the specification,
so it was unusable in practice (users were supposed to use another client,
such as Tyrus which is now donated to Jakarta - feels nice to talk again
about "Sun" donating software to Jakarta :D ). Gradually, missing items are
implemented (as users didn't understand they really had to use something
else and using the Tomcat client was not mandatory, it seems), but since
this is not part of the specification, the config is all proprietary.

Rémy

Re: Tomcat Secure WebSockets clients - hostname verification

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 6/12/18 1:06 PM, André Warnier (tomcat) wrote:
> On 12.06.2018 18:13, Mark Thomas wrote: [snip]..
>> 
>> I'll see what I can do. The major constraint is that all this has
>> to be set via Tomcat specific user properties as there is no API
>> for in the Java WebSocket API.
>> 
> 
> This is a bit OT, but I have a question since the beginning of
> this thread : Is Tomcat really supposed to provide a websocket
> *client* API ?
> 
> From the initial post, I understood that what the OP wants to do,
> is to connect, *from* a Tomcat servlet, *to* an external websocket
> server (not necessarily Tomcat). If so, it is certainly nice to
> help him doing so, but if it means providing functionalities that
> the standard Java API websocket client doesn't, does that not make
> this thing less portable ?
> 
> Or did I get this all wrong ?

IIRC, ironically, the WS server needs to be built upon a WS client, so
the WS client is simply already there. The Websocket API is part of
Java EE (or whatever it's called, now) so it won't be a part of the
standard JRE libraries. Thus there really isn't any "standard Java API
websocket client" other than those provided by vendors e.g. Tomcat.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlsgBwwACgkQHPApP6U8
pFjrThAAuQgujTj9ow5ToGLo5FHETkGLfwUS3OeNwE863jv1IZBBVe6Nqp+hapf+
oVhEWURt+VxgKmrARlNNodXyCCWQKzEI9LuRAV4yStlV0JRT5WKoNsRN+8t6OdwA
EDqhjHSXbW7dbYUkN4wOdwfQfPy8blmgbNHu2DoA9+WXIDqlkY/6C2iQ0spbJJQY
qBHILLDL8wnxPiWalB+W1azPvtMwG+J2QiFmHUZEF91Q1RmYYTkHG6a7lDyP1bVY
QcK3Len31Xh6fmDLrR8qS+PuCsCKbA6uD+aKC6PDOVCwFN/xUiT8lIIwK9Peb/5H
/k/0gTUtpkxRszQ7Of5a40fF7VYqvS6uOCFDZSTgrg/YFo/mKis3aoc6iccT8wU9
AW5KdGobgv4YHk0/uGhHMGEKxs6o7/Z9FUnpwBmXtr3Xm+ObdwY7RvmqsNrGWRAZ
RNjcUgvlBMKvUcD4LYWdynPWqJ2GRwDT/KDsqkNSy6bFphBQc3ctQ0w+qxzM2lSn
K5aaBBzAlAXDSgeOJ0UVLYbw5AOWZELMGKe0p8dQdcRGjh1hIQ4hYQzpdU85VpAC
KoYLchCMQHmmYzZknBsRfkIiMOcOF9DFzQzJ+l80k5L7R/uDaNBbAVuW6QHz9h6y
OQazNr4dOy8t7m/8gn1bwdThbkG2AXBOlfVYsQArnSVCerqeijU=
=bbuA
-END PGP SIGNATURE-

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

Re: Tomcat Secure WebSockets clients - hostname verification

[tomcat]

On 12.06.2018 18:13, Mark Thomas wrote:
[snip]..


I'll see what I can do. The major constraint is that all this has to be set via 
Tomcat
specific user properties as there is no API for in the Java WebSocket API.



This is a bit OT, but I have a question since the beginning of this thread :
Is Tomcat really supposed to provide a websocket *client* API ?

From the initial post, I understood that what the OP wants to do, is to connect, *from* a 
Tomcat servlet, *to* an external websocket server (not necessarily Tomcat).
If so, it is certainly nice to help him doing so, but if it means providing 
functionalities that the standard Java API websocket client doesn't, does that not make 
this thing less portable ?


Or did I get this all wrong ?



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

Re: Tomcat Secure WebSockets clients - hostname verification

[Mark Thomas]

On 12/06/2018 16:12, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/11/18 10:31 AM, Mark Thomas wrote:

On 11/06/18 11:47, Weiner Harald wrote:




What are your thoughts?


I'm leaning towards adding:

SSLParameters sslParams = new SSLParameters();
sslParams.setEndpointIdentificationAlgorithm("HTTPS");
sslSocket.setSSLParameters(sslParams);

unconditionally to WsWebSocketContainer.createSSLEngine()

I've been trying to think of a use case where you'd want to use
TLS without wanting to verify the host name and I can't think of
one.


Testing.


I'd argue that for testing to be meaningful you need to be using a real 
cert and an appropriate trust store.



It would be very useful to be able to configure this, so if you are
going to patch the code, please make this configurable by the client. >
See HttpsURLConnection.setHostnameVerifier

I think it's appropriate to simply match that API unless there are any
objections.


I'll see what I can do. The major constraint is that all this has to be 
set via Tomcat specific user properties as there is no API for in the 
Java WebSocket API.


Mark




- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlsf1OMACgkQHPApP6U8
pFibhw/+ODRL4BZfk9fTWxLFSEyKEJQORJgfVveHaqzsW34BzRVEx7nVGBL+T8t1
m0E+mhQY+m+YyTKsWpAzNEd/752UMFV6jHhn8Nle6I+puLpZ8tEKj4MSd2JDDC2Y
Te4mD4QwMgkdNIU8aacXqj1hJanyB4vvfSd+PpFiW/o0kWKHirpSdra87XvLqbMM
A75lKzFdyqZWJ9JBqSoQID3vLQMyBzZ+MI8XWacuT69hMWioMpiAc2iSVw73TUXO
kt9jFlP6K17QzJ3j2kmdm1TAQDupFNNs2W5M15Eo7ahj3xa137s+lZgTjI7b8rhS
dekDyD++7biKJSCnyd8XIQ+FM6UjEwCIzGtdRRNvjw+ufk9S7IDnJhD7DAeGqNOc
bq4ezaG8iFRI7h3lkJx+AeF23KaW36VEK8bbNK5phjyIfZ0crF43Xv8nTOyf1S0E
Pqj38sr9baa0JcRnYvGLS9ZDtYpDFQaQuti7p8IJs/DJ6yr+d7KvO/ZBawU6K8e0
EttmjavdB0RfooI61LBj0bazHANvhISY5xzmJIqDIYAtwlYf1Ww9X0CrpWmrPd1y
RE/M2RpXj6lcVCPqXzqSXVE/DfJXlmj5iqB4lGJBS0TrcWFvKHH5kp0reUlZNtRG
l+FshDzZylsz5tqN3DtyNjQoQN9rW181O7+j2f5exa9IS9fUgek=
=GeP9
-END PGP SIGNATURE-

-
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 Secure WebSockets clients - hostname verification

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/11/18 10:31 AM, Mark Thomas wrote:
> On 11/06/18 11:47, Weiner Harald wrote:
> 
> 
> 
>> What are your thoughts?
> 
> I'm leaning towards adding:
> 
> SSLParameters sslParams = new SSLParameters(); 
> sslParams.setEndpointIdentificationAlgorithm("HTTPS"); 
> sslSocket.setSSLParameters(sslParams);
> 
> unconditionally to WsWebSocketContainer.createSSLEngine()
> 
> I've been trying to think of a use case where you'd want to use
> TLS without wanting to verify the host name and I can't think of
> one.

Testing.

It would be very useful to be able to configure this, so if you are
going to patch the code, please make this configurable by the client.

See HttpsURLConnection.setHostnameVerifier

I think it's appropriate to simply match that API unless there are any
objections.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlsf1OMACgkQHPApP6U8
pFibhw/+ODRL4BZfk9fTWxLFSEyKEJQORJgfVveHaqzsW34BzRVEx7nVGBL+T8t1
m0E+mhQY+m+YyTKsWpAzNEd/752UMFV6jHhn8Nle6I+puLpZ8tEKj4MSd2JDDC2Y
Te4mD4QwMgkdNIU8aacXqj1hJanyB4vvfSd+PpFiW/o0kWKHirpSdra87XvLqbMM
A75lKzFdyqZWJ9JBqSoQID3vLQMyBzZ+MI8XWacuT69hMWioMpiAc2iSVw73TUXO
kt9jFlP6K17QzJ3j2kmdm1TAQDupFNNs2W5M15Eo7ahj3xa137s+lZgTjI7b8rhS
dekDyD++7biKJSCnyd8XIQ+FM6UjEwCIzGtdRRNvjw+ufk9S7IDnJhD7DAeGqNOc
bq4ezaG8iFRI7h3lkJx+AeF23KaW36VEK8bbNK5phjyIfZ0crF43Xv8nTOyf1S0E
Pqj38sr9baa0JcRnYvGLS9ZDtYpDFQaQuti7p8IJs/DJ6yr+d7KvO/ZBawU6K8e0
EttmjavdB0RfooI61LBj0bazHANvhISY5xzmJIqDIYAtwlYf1Ww9X0CrpWmrPd1y
RE/M2RpXj6lcVCPqXzqSXVE/DfJXlmj5iqB4lGJBS0TrcWFvKHH5kp0reUlZNtRG
l+FshDzZylsz5tqN3DtyNjQoQN9rW181O7+j2f5exa9IS9fUgek=
=GeP9
-END PGP SIGNATURE-

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

Re: Tomcat Secure WebSockets clients - hostname verification

[Mark Thomas]

On 11/06/18 11:47, Weiner Harald wrote:



> What are your thoughts?

I'm leaning towards adding:

SSLParameters sslParams = new SSLParameters();
sslParams.setEndpointIdentificationAlgorithm("HTTPS");
sslSocket.setSSLParameters(sslParams);

unconditionally to WsWebSocketContainer.createSSLEngine()

I've been trying to think of a use case where you'd want to use TLS
without wanting to verify the host name and I can't think of one.

Mark

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

Tomcat Secure WebSockets clients - hostname verification

[Weiner Harald]

Hello Tomcat user group,

I want a Tomcat-Servlet to connect to a secure web socket endpoint to exchange 
data with another component / server
(so my Tomcat-Servlet is acting as a WebSocket client).

Now I would also like to do some hostname verification (verify that the host to 
which I am connecting matches
the subject alternative name from the certificate) to prevent Man-in-the-middle 
attacks, see also [1].

I know that it is possible to provide an SSLContext to Tomcat through  user 
properties [2].
But an javax.net.ssl.SSLContext does not provide any configuration options for 
hostname verifiers, see JavaDoc at [3],
e.g., something like sslParams.setEndpointIdentificationAlgorithm("HTTPS"), as 
suggested by [4].

So one way to achieve this would be to patch org.apache.tomcat.websocket. 
WsWebSocketContainer.java
in the method private SSLEngine createSSLEngine(Map 
userProperties) and introduce another
user property.

But maybe there are already other solutions available to achieve Hostname 
verification in Tomcat WebSocket clients.

My code looks like this:



import javax.websocket.ClientEndpointConfig;
import javax.websocket.ContainerProvider;
import javax.websocket.Session;
import javax.websocket.WebSocketContainer;

public class MyServlet extends HttpServlet
{
  final String hostname = "otherpc";

@Override
  protected void doGet(final HttpServletRequest request, final 
HttpServletResponse response)
  throws ServletException, IOException
{
System.setProperty("javax.net.ssl.trustStorePassword", "My123456");
System.setProperty("javax.net.ssl.trustStoreType", "PKCS12");
System.setProperty("javax.net.ssl.trustStore", "C:\\RootCACertificate.pfx");
final URI uri = URI.create("wss://" + hostname + ":8443/websocket");
final WebSocketContainer container = 
ContainerProvider.getWebSocketContainer();
final ClientEndpointConfig config = 
ClientEndpointConfig.Builder.create().build();
final Session session = container.connectToServer(MyEndpoint.class, config, 
uri);
   // more stuff 
}



What are your thoughts?

Thank you very much for your time!


Harald.

[1] https://tersesystems.com/blog/2014/03/23/fixing-hostname-verification/

[2] https://www.mail-archive.com/users@tomcat.apache.org/msg125312.html

[3] https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html

[4] https://stackoverflow.com/a/18174689


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

Re: x-forwarded-X stuff and websockets

[Johan Compagner]

>
>
>
> Are you sure the L7 load balancer can handle HTTP upgrade? Looking at
> the Amazon docs you want an "Application load balancer" rather than a
> "Classic load balancer"
>
> My guess is that the load balancer is removing one or more of the
> headers Tomcat depends on to identify the request as a WebSocket
> request. Can you use tcpdump to capture a request that returns a 404?
> Looking at that trace should point us in the right direction.
>
> Mark
>


thx mark

thats very likely it.

https://aws.amazon.com/elasticloadbalancing/details/#compare

weird thing is websockets are working with classic tcp/layer 4 ...
I guess that is kind of logical because everything is just send as is...

and the the http/https layer 7 one of classes really doesn't support it
correctly

And ALB doesnt support smtp and other ports that we need (At least that is
what is told to me)

And in the end we also need sticky session support and so (what only an
http or application load balancer supports)
so we have here an very annoying problem that any solution we pick will not
support all features that we need...


-- 
Johan Compagner
Servoy

Re: x-forwarded-X stuff and websockets

[Mark Thomas]

On 26/04/18 08:54, Johan Compagner wrote:
> Hi,
> 
> We have a tomcat on an amazon service with for now a ELB L4 (tcp
> loadbalancer, with ssl offloading) before it
> 
> That works for the most part just fine, except we don't know that we are in
> ssl mode or not
> Our application have support for that to look at the x-forwarded-proto
> header (and some other fallbacks) to see what is really the scheme the end
> users uses
> 
> So we switch to a ELB L7 load balancer which is the http load balancer that
> will add those x-forwarded-proto for us. And yes i checked they are on all
> the reques tthen.
> 
> This seems to work for all kind of connections to servlets/files/filters
> and so on except websockets
> Suddenly if we switch that on then all the websocket connections are
> returning 404 (i see that in the browser and in the tomcat access log)
> Can't find any other thing in the log files that would give me a clue what
> is happening
> 
> Does anybody has an idea why suddenly the http upgrade stuff to websockets
> (wss protocol) are suddenly seen as 404/NOT_FOUND ?

Are you sure the L7 load balancer can handle HTTP upgrade? Looking at
the Amazon docs you want an "Application load balancer" rather than a
"Classic load balancer"

My guess is that the load balancer is removing one or more of the
headers Tomcat depends on to identify the request as a WebSocket
request. Can you use tcpdump to capture a request that returns a 404?
Looking at that trace should point us in the right direction.

Mark

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

x-forwarded-X stuff and websockets

[Johan Compagner]

Hi,

We have a tomcat on an amazon service with for now a ELB L4 (tcp
loadbalancer, with ssl offloading) before it

That works for the most part just fine, except we don't know that we are in
ssl mode or not
Our application have support for that to look at the x-forwarded-proto
header (and some other fallbacks) to see what is really the scheme the end
users uses

So we switch to a ELB L7 load balancer which is the http load balancer that
will add those x-forwarded-proto for us. And yes i checked they are on all
the reques tthen.

This seems to work for all kind of connections to servlets/files/filters
and so on except websockets
Suddenly if we switch that on then all the websocket connections are
returning 404 (i see that in the browser and in the tomcat access log)
Can't find any other thing in the log files that would give me a clue what
is happening

Does anybody has an idea why suddenly the http upgrade stuff to websockets
(wss protocol) are suddenly seen as 404/NOT_FOUND ?


-- 
Johan Compagner
Servoy

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Guang Chao]

On Thu, Aug 10, 2017 at 12:46 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 8/9/17 11:35 AM, Mark Thomas wrote:
> > On 09/08/17 16:09, David Wall wrote:
> >> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> >> Atmosphere Websockets.
> >>
> >> We have had reports of sessions logging out while users are
> >> active with our Vaadin-based application.  This has been
> >> frustrating as we can't seem to track down why Tomcat's session
> >> is not being updated, but figure it's something to do with the
> >> websockets/push not updating Tomcat reliably.
> >>
> >> Our app shows a "last sent to server" timestamp that seems to
> >> keep current with user activity, updating as the user clicks on
> >> buttons, checkboxes, etc.
> >>
> >> We also have a "list of active sessions" screen that shows all
> >> active sessions including the HttpSession.getCreationTime() and
> >> HttpSession.getLastAccessedTime().  We see it appears as if the
> >> last accessed time stops being updated when using simple forms
> >> that perhaps update via websockets rather than HTTP requests.
> >> Our "last sent to server" timestamp shows each of these clicks
> >> updating it, but the HttpSession.getLastAccessedTime() is not
> >> updating.
> >>
> >> Is there something about push/websockets or anything else that
> >> would cause the HttpSession access time not to update?  I don't
> >> think we have a way to update it ourselves as I believe it's
> >> managed by Tomcat itself, but as Tomcat is handling the websocket
> >> requests, it's unclear why they are not tied to the HttpSession.
> >>
> >> Anybody have any ideas?  Thanks as we have a lot of frustrated
> >> users who would love for us to find out what's going astray.
> >
> > What you are seeing is expected behaviour. This was discussed in
> > the WebSocket EG. The short version is: - WebSocket requests don't
> > update the session's last accessed time - you need an HTTP request
> > from the browser to update the session's last accessed time (and
> > update the expiry time of the browser's session cookie) - so the
> > application has to do periodic HTTP requests.
> >
> > You can reduce the frequency of these requests by extending the
> > session timeout (remembering you need an HTTP request after this to
> > update the browser's cookie). You then need to be careful to reduce
> > the timeout again once WebSocket comms end.
>
> Websocket ignoramus, here. Is there a way for (websocket) application
> code on the server side to trigger a "touch" of the HttpSession that
> is linked with the connection? Or is the problem that the websocket
> connection and the HTTP connection are essentially independent?
>
>
Maybe just have a javascript with settimeout to poll heartbeat via http
request.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmLPEUACgkQHPApP6U8
> pFjVpRAAhIk//uWfkihpjwqp75MwDqe4mlAN3zbdvLoa4EU0QJyA8fZRnIFuO7Gg
> ksQYycpuGniEMPQH+l4Mb3T5/KogTkY3DZrBRh7vN+8oA3ELayuqTxDAdNjjsnmg
> uKWeYv3obL8pZQuSb5hVFXx4Dfe6pAXWk7CwuHls5Cs97lRqvN9C5lQM1QPArPpt
> nqNnDUm7HHmrSZVo82bdJxgXfpRXnoIg5qie3wGURHzdQK4JZGpZY7jJDAmM/HTW
> QNHg2saIFR1ce5YdGD2UZ5KbcVylfP1vX3oQZj9O+ytRGW37qiuAqjkuLZ73gJt7
> Xlz/6hAwxq+RMsfysJQitdytAcZj/BZQs3OesvcYxSpG9M2zOs3y6Pi+V7ieRk+i
> GbwGFzlGzmyA8LWdpgWFNHjGPlGwa04ALtp/zN6MoovULZs9XskUd3PBM622roJ2
> A+BUrr1GHo8nbcnStcTdL9JQuyrjFPOyyT+FUQR0pWk/PQKutpMzqoKYgK/CWcBv
> bxiREyfCOxTMLKkWXp4tZV6zMakdk+/srbPJbW35HS7PJT6iTP1ldWjh2hw4XXbD
> Jn1OXXJQZ6AHDPGMpKSAvVeCQre/jb6yvFhsgHYz1VjZs5dIw8kqgy5AZrgnjwcX
> 9azk5oNJon6AplWbnN0QVddP+rmxgiPwyvu7ywgxrlgdU3ykazo=
> =h6fX
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Guang
<http://javadevnotes.com/java-float-to-string-without-exponential-scientific-notation>

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Mark Thomas]

On 09/08/17 17:46, Christopher Schultz wrote:

> Websocket ignoramus, here. Is there a way for (websocket) application
> code on the server side to trigger a "touch" of the HttpSession that
> is linked with the connection? Or is the problem that the websocket
> connection and the HTTP connection are essentially independent?

Through standard APIs, no.

You can get a reference to the session object during the initial
handshake but you'd have to keep a reference to it and then cast it to
an internal Tomcat object and poke around via reflection to get Tomcat's
internal session object and call access().

If the Servlet EG could be convinced to add an access() method... (this
would have to wait until Servlet 4.next / Java EE 9)

We could provide an internal API that would make this a lot easier
(still requires casting but no reflection). That assumes it is always
safe to let an application update a session's last access time. I can't
think of a good reason not to allow this.

Mark

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

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/9/17 11:35 AM, Mark Thomas wrote:
> On 09/08/17 16:09, David Wall wrote:
>> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
>> Atmosphere Websockets.
>> 
>> We have had reports of sessions logging out while users are
>> active with our Vaadin-based application.  This has been
>> frustrating as we can't seem to track down why Tomcat's session
>> is not being updated, but figure it's something to do with the
>> websockets/push not updating Tomcat reliably.
>> 
>> Our app shows a "last sent to server" timestamp that seems to
>> keep current with user activity, updating as the user clicks on
>> buttons, checkboxes, etc.
>> 
>> We also have a "list of active sessions" screen that shows all
>> active sessions including the HttpSession.getCreationTime() and 
>> HttpSession.getLastAccessedTime().  We see it appears as if the
>> last accessed time stops being updated when using simple forms
>> that perhaps update via websockets rather than HTTP requests.
>> Our "last sent to server" timestamp shows each of these clicks
>> updating it, but the HttpSession.getLastAccessedTime() is not
>> updating.
>> 
>> Is there something about push/websockets or anything else that
>> would cause the HttpSession access time not to update?  I don't
>> think we have a way to update it ourselves as I believe it's
>> managed by Tomcat itself, but as Tomcat is handling the websocket
>> requests, it's unclear why they are not tied to the HttpSession.
>> 
>> Anybody have any ideas?  Thanks as we have a lot of frustrated
>> users who would love for us to find out what's going astray.
> 
> What you are seeing is expected behaviour. This was discussed in
> the WebSocket EG. The short version is: - WebSocket requests don't
> update the session's last accessed time - you need an HTTP request
> from the browser to update the session's last accessed time (and
> update the expiry time of the browser's session cookie) - so the
> application has to do periodic HTTP requests.
> 
> You can reduce the frequency of these requests by extending the
> session timeout (remembering you need an HTTP request after this to
> update the browser's cookie). You then need to be careful to reduce
> the timeout again once WebSocket comms end.

Websocket ignoramus, here. Is there a way for (websocket) application
code on the server side to trigger a "touch" of the HttpSession that
is linked with the connection? Or is the problem that the websocket
connection and the HTTP connection are essentially independent?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmLPEUACgkQHPApP6U8
pFjVpRAAhIk//uWfkihpjwqp75MwDqe4mlAN3zbdvLoa4EU0QJyA8fZRnIFuO7Gg
ksQYycpuGniEMPQH+l4Mb3T5/KogTkY3DZrBRh7vN+8oA3ELayuqTxDAdNjjsnmg
uKWeYv3obL8pZQuSb5hVFXx4Dfe6pAXWk7CwuHls5Cs97lRqvN9C5lQM1QPArPpt
nqNnDUm7HHmrSZVo82bdJxgXfpRXnoIg5qie3wGURHzdQK4JZGpZY7jJDAmM/HTW
QNHg2saIFR1ce5YdGD2UZ5KbcVylfP1vX3oQZj9O+ytRGW37qiuAqjkuLZ73gJt7
Xlz/6hAwxq+RMsfysJQitdytAcZj/BZQs3OesvcYxSpG9M2zOs3y6Pi+V7ieRk+i
GbwGFzlGzmyA8LWdpgWFNHjGPlGwa04ALtp/zN6MoovULZs9XskUd3PBM622roJ2
A+BUrr1GHo8nbcnStcTdL9JQuyrjFPOyyT+FUQR0pWk/PQKutpMzqoKYgK/CWcBv
bxiREyfCOxTMLKkWXp4tZV6zMakdk+/srbPJbW35HS7PJT6iTP1ldWjh2hw4XXbD
Jn1OXXJQZ6AHDPGMpKSAvVeCQre/jb6yvFhsgHYz1VjZs5dIw8kqgy5AZrgnjwcX
9azk5oNJon6AplWbnN0QVddP+rmxgiPwyvu7ywgxrlgdU3ykazo=
=h6fX
-END PGP SIGNATURE-

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

Re: Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

On 8/9/17 8:35 AM, Mark Thomas wrote:

On 09/08/17 16:09, David Wall wrote:

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
Atmosphere Websockets.

We have had reports of sessions logging out while users are active with
our Vaadin-based application.  This has been frustrating as we can't
seem to track down why Tomcat's session is not being updated, but figure
it's something to do with the websockets/push not updating Tomcat reliably.

Our app shows a "last sent to server" timestamp that seems to keep
current with user activity, updating as the user clicks on buttons,
checkboxes, etc.

We also have a "list of active sessions" screen that shows all active
sessions including the HttpSession.getCreationTime() and
HttpSession.getLastAccessedTime().  We see it appears as if the last
accessed time stops being updated when using simple forms that perhaps
update via websockets rather than HTTP requests.  Our "last sent to
server" timestamp shows each of these clicks updating it, but the
HttpSession.getLastAccessedTime() is not updating.

Is there something about push/websockets or anything else that would
cause the HttpSession access time not to update?  I don't think we have
a way to update it ourselves as I believe it's managed by Tomcat itself,
but as Tomcat is handling the websocket requests, it's unclear why they
are not tied to the HttpSession.

Anybody have any ideas?  Thanks as we have a lot of frustrated users who
would love for us to find out what's going astray.

What you are seeing is expected behaviour. This was discussed in the
WebSocket EG. The short version is:
- WebSocket requests don't update the session's last accessed time
- you need an HTTP request from the browser to update the session's
   last accessed time (and update the expiry time of the browser's
   session cookie)
- so the application has to do periodic HTTP requests.

You can reduce the frequency of these requests by extending the session
timeout (remembering you need an HTTP request after this to update the
browser's cookie). You then need to be careful to reduce the timeout
again once WebSocket comms end.

Mark


Thanks, Mark.  Let me check but it is my impression that a HEARTBEAT 
type request is sent every 5 minutes, but I'll investigate further. You 
at least answered my question and we should be able to find a solution 
of that nature.


David

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

Re: Session timeout despite user activity - websockets on Tomcat 8.5.16

[Mark Thomas]

On 09/08/17 16:09, David Wall wrote:
> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> Atmosphere Websockets.
> 
> We have had reports of sessions logging out while users are active with
> our Vaadin-based application.  This has been frustrating as we can't
> seem to track down why Tomcat's session is not being updated, but figure
> it's something to do with the websockets/push not updating Tomcat reliably.
> 
> Our app shows a "last sent to server" timestamp that seems to keep
> current with user activity, updating as the user clicks on buttons,
> checkboxes, etc.
> 
> We also have a "list of active sessions" screen that shows all active
> sessions including the HttpSession.getCreationTime() and
> HttpSession.getLastAccessedTime().  We see it appears as if the last
> accessed time stops being updated when using simple forms that perhaps
> update via websockets rather than HTTP requests.  Our "last sent to
> server" timestamp shows each of these clicks updating it, but the
> HttpSession.getLastAccessedTime() is not updating.
> 
> Is there something about push/websockets or anything else that would
> cause the HttpSession access time not to update?  I don't think we have
> a way to update it ourselves as I believe it's managed by Tomcat itself,
> but as Tomcat is handling the websocket requests, it's unclear why they
> are not tied to the HttpSession.
> 
> Anybody have any ideas?  Thanks as we have a lot of frustrated users who
> would love for us to find out what's going astray.

What you are seeing is expected behaviour. This was discussed in the
WebSocket EG. The short version is:
- WebSocket requests don't update the session's last accessed time
- you need an HTTP request from the browser to update the session's
  last accessed time (and update the expiry time of the browser's
  session cookie)
- so the application has to do periodic HTTP requests.

You can reduce the frequency of these requests by extending the session
timeout (remembering you need an HTTP request after this to update the
browser's cookie). You then need to be careful to reduce the timeout
again once WebSocket comms end.

Mark

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

Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
Atmosphere Websockets.


We have had reports of sessions logging out while users are active with 
our Vaadin-based application.  This has been frustrating as we can't 
seem to track down why Tomcat's session is not being updated, but figure 
it's something to do with the websockets/push not updating Tomcat reliably.


Our app shows a "last sent to server" timestamp that seems to keep 
current with user activity, updating as the user clicks on buttons, 
checkboxes, etc.


We also have a "list of active sessions" screen that shows all active 
sessions including the HttpSession.getCreationTime() and 
HttpSession.getLastAccessedTime().  We see it appears as if the last 
accessed time stops being updated when using simple forms that perhaps 
update via websockets rather than HTTP requests.  Our "last sent to 
server" timestamp shows each of these clicks updating it, but the 
HttpSession.getLastAccessedTime() is not updating.


Is there something about push/websockets or anything else that would 
cause the HttpSession access time not to update?  I don't think we have 
a way to update it ourselves as I believe it's managed by Tomcat itself, 
but as Tomcat is handling the websocket requests, it's unclear why they 
are not tied to the HttpSession.


Anybody have any ideas?  Thanks as we have a lot of frustrated users who 
would love for us to find out what's going astray.


David


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

finally websockets close correctly

[Cristian Lorenzetto]

oh finally you resolved the problem with websockets  when is closed... when
i told you 2 years ago ... i didnt hear me

Re: parallel deployment and websockets

[Johan Compagner]

On 31 May 2017 at 10:11, Mark Thomas  wrote:

>
> >>
> >>
> > would a feature request be accepted for this that there can be a cookie
> set
> > where that "load balancer" would also look at?
> > and that  cookie always make sure that it goes to the context it started
> > from as long as that context is there?
>
> Maybe.
>
> What is the use case? Why can't a new WebSocket connection be created to
> the new version of the web application?
>

because it looses then state.
Like i said below, our application is a statefull application but we use
websocket what was previously ajax request to push back and forward changes
to server and client
(so a data change on the server is pushed right away to the client)

We have our own session tracking over the websocket url:

wss://domain/websocketendpoint/sessionuuidparam

the first time that sessionuuidparam is null but then we push that value to
the client and store it in the session storage (so that tab in the browser)
and if we do a refresh or a reconnect then we send that session uuid to the
server and the server will connect that new websocket endpoint to our
"session" object

So a new context would not find that session object because i guess that is
a fully new classloader/application deploy...
so we lost the session.
In the ajax version this would not happen because that is all pure async
http request to the server with a http session object..



>
> > Because it is quite annoying that it is tied to a jsessionid of a
> > HttpSession that should then be created and kept alive for the whole
> > websocket session..
> >
> > i can do something like this:
> >
> > https://stackoverflow.com/questions/17936440/accessing-httpsession-from-
> httpservletrequest-in-a-web-socket-serverendpoint
> >
> > but isn't that kind of doing something that shouldn't be done? Like
> keeping
> > a reference to a http session?
> >
> > Even if i do the above then still i need to "touch" the session on every
> > websocket request to keep it alive
> > Or set the max idle time out to -1 so it never by itself invalidates()
> > And then when i know the websocket session is really gone i will call
> > invalidate() on it myself..
>
> If you are invalidating the HTTP session once the WebSocket connection
> closes, why keep the session alive in the first place?
>


No we wouldn't close it on the websocket connection close, but on the
timeout of the Session object that is behind that connection
And if before the time out happens a new websocket connection is coming in
(with the above url) then we quickly re attach the session object to that
new endpoint and it will go on

only after a while if there is no new websocket being setup, we invalidate
the session object (and then we could also invalidate the http session that
we stored)


So in the end this is just kind of the same as http sessions in tomcat...
but then real session support over multiply request for websockets
And we don't use a cookie but purely have the id always in the url because
this way multiply tabs in the browser are always independent of each other.

So it would be nice if tomcat would have versioning support for websockets
under the hood...
Like a setting that we could turn on and then when an upgrade happens
tomcat auto sends a cookie which it reuses to connect to the right context
version

johan

Re: parallel deployment and websockets

[Mark Thomas]

On 31/05/17 08:38, Johan Compagner wrote:
>>
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>> Mark
>>
>>
> would a feature request be accepted for this that there can be a cookie set
> where that "load balancer" would also look at?
> and that  cookie always make sure that it goes to the context it started
> from as long as that context is there?

Maybe.

What is the use case? Why can't a new WebSocket connection be created to
the new version of the web application?

> Because it is quite annoying that it is tied to a jsessionid of a
> HttpSession that should then be created and kept alive for the whole
> websocket session..
> 
> i can do something like this:
> 
> https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint
> 
> but isn't that kind of doing something that shouldn't be done? Like keeping
> a reference to a http session?
> 
> Even if i do the above then still i need to "touch" the session on every
> websocket request to keep it alive
> Or set the max idle time out to -1 so it never by itself invalidates()
> And then when i know the websocket session is really gone i will call
> invalidate() on it myself..

If you are invalidating the HTTP session once the WebSocket connection
closes, why keep the session alive in the first place?

Mark


> 
> But this is all quite cumbersome
> 
> We just have state there is no way around it, but the communication between
> server and client is after the first startup completely over websocket
> (just like ajax before)>
> For example it would be nice if tomcat did this just under the hood. if
> tomcat upgrades a http request to a websocket then it will also just push a
> small cookie on it to know which context version it was on...
> 
> johan
> 


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

Re: parallel deployment and websockets

[Johan Compagner]

>
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
> Mark
>
>
would a feature request be accepted for this that there can be a cookie set
where that "load balancer" would also look at?
and that  cookie always make sure that it goes to the context it started
from as long as that context is there?

Because it is quite annoying that it is tied to a jsessionid of a
HttpSession that should then be created and kept alive for the whole
websocket session..

i can do something like this:

https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint

but isn't that kind of doing something that shouldn't be done? Like keeping
a reference to a http session?

Even if i do the above then still i need to "touch" the session on every
websocket request to keep it alive
Or set the max idle time out to -1 so it never by itself invalidates()
And then when i know the websocket session is really gone i will call
invalidate() on it myself..

But this is all quite cumbersome

We just have state there is no way around it, but the communication between
server and client is after the first startup completely over websocket
(just like ajax before)

For example it would be nice if tomcat did this just under the hood. if
tomcat upgrades a http request to a websocket then it will also just push a
small cookie on it to know which context version it was on...

johan

Re: parallel deployment and websockets

[Ludovic Pénet]

In a similar situation, I do the following :
* go full stateless, use no session ;
* configure WS client to frequently reconnect
* use atmosphere with an internal JMS backend, such as ActiveMQ, to share data 
transparently between parallely deployed versions.

With Atmosphere, you avoid losing messages on reconnections. 

Hope this helps.

Ludovic

Le 30 mai 2017 12:40:45 GMT+02:00, Johan Compagner  a 
écrit :
>>
>> > But now i have websockets, if i connect to ##1 first and i have the
>end
>> > point there
>> > Then i add a ##2 version of the context
>> > then i guess a new user that opens a websocket will go to ##2
>> > but if the existing user does a refresh in the browser then it will
>also
>> > suddenly go to ##2 i guess?
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the
>session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>
>
>ah so for this to work we need to force a http session to be created?
>so the cookie is set and the http session is there?
>problem is a bit that all communication is then going through the
>websocket
>so the session could even just timeout, because we don't hit it anymore
>
>i do see when creating a websocket, request.getSession(false) is called
>(multiply times by the way, a lot goes wrong when you have a breakpoint
>on
>that method, but thats another story)
>but it isn't when it is just alive. So  do i need to call something
>every
>time on the incomming() call in the endpoint to keep the http session
>alive..
>
>johan

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: parallel deployment and websockets

[Johan Compagner]

>
> > But now i have websockets, if i connect to ##1 first and i have the end
> > point there
> > Then i add a ##2 version of the context
> > then i guess a new user that opens a websocket will go to ##2
> > but if the existing user does a refresh in the browser then it will also
> > suddenly go to ##2 i guess?
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>


ah so for this to work we need to force a http session to be created?
so the cookie is set and the http session is there?
problem is a bit that all communication is then going through the websocket
so the session could even just timeout, because we don't hit it anymore

i do see when creating a websocket, request.getSession(false) is called
(multiply times by the way, a lot goes wrong when you have a breakpoint on
that method, but thats another story)
but it isn't when it is just alive. So  do i need to call something every
time on the incomming() call in the endpoint to keep the http session
alive..

johan

Re: parallel deployment and websockets

[Mark Thomas]

On 30/05/17 11:09, Johan Compagner wrote:
> Hi,
> 
> if i read this:
> 
> http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment
> 
> then i see it will go to the "old" version of a war based on session
> information
> i guess this is jsessionid?
> 
> So a refresh in the browser or another request with the jsessionid will go
> to the version it started with i guess?
> 
> But now i have websockets, if i connect to ##1 first and i have the end
> point there
> Then i add a ##2 version of the context
> then i guess a new user that opens a websocket will go to ##2
> but if the existing user does a refresh in the browser then it will also
> suddenly go to ##2 i guess?

It depends. If the URL in the HTTP UPGRADE request includes the session
ID, and that session ID is still valid in ##1, then the WebSocket
request will be handled by ##1.

Mark


> 
> (we have session info over the websocket url like a jsessionid... but that
> will not map in the other later version of the context i guess)
> 


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

parallel deployment and websockets

[Johan Compagner]

Hi,

if i read this:

http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment

then i see it will go to the "old" version of a war based on session
information
i guess this is jsessionid?

So a refresh in the browser or another request with the jsessionid will go
to the version it started with i guess?

But now i have websockets, if i connect to ##1 first and i have the end
point there
Then i add a ##2 version of the context
then i guess a new user that opens a websocket will go to ##2
but if the existing user does a refresh in the browser then it will also
suddenly go to ##2 i guess?

(we have session info over the websocket url like a jsessionid... but that
will not map in the other later version of the context i guess)

-- 
Johan Compagner
Servoy

Re: Websockets : differents behaviours on connection when using WS or WSS

[Mark Thomas]

On 18/07/2016 16:25, l.pe...@senat.fr wrote:
> Hi.
> 
> I am using Tomcat 8.0.36 with Atmosphere 2.4.5 (
> https://github.com/Atmosphere/atmosphere ) to implement WebSockets with
> fallbacks such as long polling.

Can you reproduce this without Atmosphere? If not, that suggests an
Atmosphere bug. If yes, then it is likely there is a Tomcat bug.

It could also be a bug in you test case.

The simpler the test case the easier it will be to identify the root cause.



> So, is this difference in behaviour to be expected ?

No.

> Is there some point
> in spec that I missed that commands it ?

No.

Mark


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

Re: Websockets : differents behaviours on connection when using WS or WSS

[l.pe...@senat.fr]

On 18/07/2016 16:25, l.pe...@senat.fr wrote:

Hi.

I am using Tomcat 8.0.36 with Atmosphere 2.4.5 ( 
https://github.com/Atmosphere/atmosphere ) to implement WebSockets 
with fallbacks such as long polling.


I am writing tests using Tomcat JSR356 implementation.

I studied your WebSocket samples and I am using a fake trustore :

ClientEndpointConfig cec = 
ClientEndpointConfig.Builder.create().build();

File keyStorePath = new File("path/to/test.keystore");
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PROPERTY, 
keyStorePath.getAbsolutePath());
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PWD_PROPERTY, 
"pouetpouet");


or similarly I am setting the 
WsWebSocketContainer.SSL_CONTEXT_PROPERTY to a passthrough ssl 
context, accepting all certificates (it's just for tests, it's ok).



My test looks like :

WebSocketContainer container = 
ContainerProvider.getWebSocketContainer();
RecordingReceivedMessagesSocket socket = new 
RecordingReceivedMessagesSocket();


URI echoUri = new URI(getWSTestURI("/ws/delaislimites"));

ClientEndpointConfig cec = 
ClientEndpointConfig.Builder.create().build();

File keyStorePath = new File("path/to/test.keystore");
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PROPERTY, 
keyStorePath.getAbsolutePath());
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PWD_PROPERTY, 
"pouetpouet");


Session wsSession = container.connectToServer(socket, cec, 
echoUri);
I realised that my message was incomplete and, by the way, found the 
answer myself.


When I do not go SSL, I do not call the same version of connectToServer. 
I am doing


Session wsSession = container.connectToServer(socket, echoUri);

This version os connectToServer gets an Object rather than a endpoint as 
first parameter and, among other things, looks for the ClientEndpoint 
annotation.


If it finds it, it wraps it in a PojoEndpointClient (pojo is the first 
parameter of connectToServer) :


 Endpoint ep = new PojoEndpointClient(pojo, 
Arrays.asList(annotation.decoders()));


So, if I do

container.connectToServer(new PojoEndpointClient(socket, new 
ArrayList<>()), cec, echoUri);


everything is fine, because of the inits that PojoEndpointClient does.

Sorry for the noise.

Ludovic





socket.close();
log.info("Attente de la fermeture de la socket");
Assert.assertTrue(socket.awaitClose(10,TimeUnit.SECONDS));
log.info("La socket doit avoir reçu OK");
Assert.assertTrue(socket.getReceivedMessages().contains("OK"));
Assert.assertTrue(true);

RecordingReceivedMessagesSocket class looks like :


@ClientEndpoint
@Log4j2
@Getter
public class RecordingReceivedMessagesSocket extends BaseTestSocket
{
List receivedMessages = new ArrayList<>();

@OnMessage
public String onMessage(String msg, Session session)
{
log.info("Message reçu : {}", msg);
this.receivedMessages.add(msg);
return msg;
}
}

@ClientEndpoint
@Log4j2
@Getter
public class BaseTestSocket extends Endpoint
{
private Session session;

private final CountDownLatch closeLatch;

public BaseTestSocket()
{
this.closeLatch = new CountDownLatch(1);
}

@OnOpen
@Override
public void onOpen(Session session, EndpointConfig config)
{
log.info("Connexion établie.");
this.session = session;
}

public boolean awaitClose(int duration, TimeUnit unit) throws 
InterruptedException

{
return this.closeLatch.await(duration,unit);
}

@OnClose
@Override
public void onClose(Session session, CloseReason reason)
{
log.info("Connexion fermée.");
this.closeLatch.countDown();
}

public void write(String message) throws IOException {
this.session.getBasicRemote().sendText(message);
}

public void writeObject(Object object) throws IOException, 
EncodeException {

this.session.getBasicRemote().sendObject(object);
}

public void close() throws IOException {
this.session.close();
}
}


When I implement getWSTestURI() so that it returns a url for a non 
encrypted request, such as ws://localhost/8084/ws/delaislimites :


* RecordingReceivedMessagesSocket.onMessage gets called with the 
immediate server reply ("OK").



The ServerEndPoint looks like :


@Log4j2
@ManagedService(path = "/ws/delaislimites")
public class WSDelaisLimites {
@Inject
private BroadcasterFactory factory;

@Inject
private AtmosphereResourceFactory resourceFactory;

@Inject
private MetaBroadcaster metaBroadcaster;

@Ready(encoders = {JacksonEncoder.class})
@DeliverTo(DeliverTo.DELIVER_TO.ALL)
public String onReady(final AtmosphereResource r) {
l

Websockets : differents behaviours on connection when using WS or WSS

[l.pe...@senat.fr]

Hi.

I am using Tomcat 8.0.36 with Atmosphere 2.4.5 ( 
https://github.com/Atmosphere/atmosphere ) to implement WebSockets with 
fallbacks such as long polling.


I am writing tests using Tomcat JSR356 implementation.

I studied your WebSocket samples and I am using a fake trustore :

ClientEndpointConfig cec = 
ClientEndpointConfig.Builder.create().build();

File keyStorePath = new File("path/to/test.keystore");
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PROPERTY, 
keyStorePath.getAbsolutePath());
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PWD_PROPERTY, 
"pouetpouet");


or similarly I am setting the WsWebSocketContainer.SSL_CONTEXT_PROPERTY 
to a passthrough ssl context, accepting all certificates (it's just for 
tests, it's ok).



My test looks like :

WebSocketContainer container = 
ContainerProvider.getWebSocketContainer();
RecordingReceivedMessagesSocket socket = new 
RecordingReceivedMessagesSocket();


URI echoUri = new URI(getWSTestURI("/ws/delaislimites"));

ClientEndpointConfig cec = 
ClientEndpointConfig.Builder.create().build();

File keyStorePath = new File("path/to/test.keystore");
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PROPERTY, 
keyStorePath.getAbsolutePath());
cec.getUserProperties().put(WsWebSocketContainer.SSL_TRUSTSTORE_PWD_PROPERTY, 
"pouetpouet");


Session wsSession = container.connectToServer(socket, cec, 
echoUri);


socket.close();
log.info("Attente de la fermeture de la socket");
Assert.assertTrue(socket.awaitClose(10,TimeUnit.SECONDS));
log.info("La socket doit avoir reçu OK");
Assert.assertTrue(socket.getReceivedMessages().contains("OK"));
Assert.assertTrue(true);

RecordingReceivedMessagesSocket class looks like :


@ClientEndpoint
@Log4j2
@Getter
public class RecordingReceivedMessagesSocket extends BaseTestSocket
{
List receivedMessages = new ArrayList<>();

@OnMessage
public String onMessage(String msg, Session session)
{
log.info("Message reçu : {}", msg);
this.receivedMessages.add(msg);
return msg;
}
}

@ClientEndpoint
@Log4j2
@Getter
public class BaseTestSocket extends Endpoint
{
private Session session;

private final CountDownLatch closeLatch;

public BaseTestSocket()
{
this.closeLatch = new CountDownLatch(1);
}

@OnOpen
@Override
public void onOpen(Session session, EndpointConfig config)
{
log.info("Connexion établie.");
this.session = session;
}

public boolean awaitClose(int duration, TimeUnit unit) throws 
InterruptedException

{
return this.closeLatch.await(duration,unit);
}

@OnClose
@Override
public void onClose(Session session, CloseReason reason)
{
log.info("Connexion fermée.");
this.closeLatch.countDown();
}

public void write(String message) throws IOException {
this.session.getBasicRemote().sendText(message);
}

public void writeObject(Object object) throws IOException, 
EncodeException {

this.session.getBasicRemote().sendObject(object);
}

public void close() throws IOException {
this.session.close();
}
}


When I implement getWSTestURI() so that it returns a url for a non 
encrypted request, such as ws://localhost/8084/ws/delaislimites :


* RecordingReceivedMessagesSocket.onMessage gets called with the 
immediate server reply ("OK").



The ServerEndPoint looks like :


@Log4j2
@ManagedService(path = "/ws/delaislimites")
public class WSDelaisLimites {
@Inject
private BroadcasterFactory factory;

@Inject
private AtmosphereResourceFactory resourceFactory;

@Inject
private MetaBroadcaster metaBroadcaster;

@Ready(encoders = {JacksonEncoder.class})
@DeliverTo(DeliverTo.DELIVER_TO.ALL)
public String onReady(final AtmosphereResource r) {
log.info("Browser {} connected.", r.uuid());
return "OK";
}

/**
 * Invoked when the client disconnect or when an unexpected closing 
of the underlying connection happens.

 *
 * @param event
 */
@Disconnect
public void onDisconnect(AtmosphereResourceEvent event) {
if (event.isCancelled()) {
log.info("Browser {} unexpectedly disconnected", 
event.getResource().uuid());

} else if (event.isClosedByClient()) {
log.info("Browser {} closed the connection", 
event.getResource().uuid());

}
}

/* ... */
@Message
public String onMessage(String message) throws IOException {
StringBuilder sb = new StringBuilder();
sb.append("Reçu le message texte ");
sb.append(message);
log.info(sb.toStr

Weird problem with WebSockets

[Edwin Quijada]

Hi!
I have developed an app using websocket. I am using servers to upload my app in 
DigitalOcean but here the websockets doesnt work but using another server 
server4U everuthing is fine. I am using Tomcat 8.5.3 somebody has any cluee, 
any, about this behavour , the only thing that I think is DigitalOcean myabe 
has any proxy in front of their servers , Tomcat is so weird with this, and 
server4U dont.


I tested my app with WildFly in DigitalOcean and it works fine. I know maybe 
this is not a problem or who knows but I want just a cluee.


Thks In Advance

Re: WebSockets

[Martin Funk]

Coming from the TomEE, I see there, that while the server starts up it logs
all kind of information of web-apps and services it found in its
deployment. For example REST Endpoints with the Path they are served under
are logged.

I found that quit nice for a freshmen to know which services are served.

At poking around with the WebSockets I had a hard time to figure out if the
HTML was wrong or if the server just didn't serve the Endpoint.

So basically for debugging reasons.

mf

2016-07-03 18:57 GMT+02:00 Mark Thomas :

> On 03/07/2016 11:04, Martin Funk wrote:
> > Hi,
> >
> > I'm into my first steps of using the WebSocket API.
> > Things are quite nice so far, WebSockets, used the right way, might open
> up
> > a complete new type of WebApplications.
> >
> > I've got a question though, is there a way to configure Tomcat to
> announce
> > the annotated ServerEndpoints, it comes across while starting the server,
> > in the catalina log?
>
> No. That does not appear to be logged at any level.
>
> What are you trying to achieve?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: WebSockets

[Mark Thomas]

On 03/07/2016 11:04, Martin Funk wrote:
> Hi,
> 
> I'm into my first steps of using the WebSocket API.
> Things are quite nice so far, WebSockets, used the right way, might open up
> a complete new type of WebApplications.
> 
> I've got a question though, is there a way to configure Tomcat to announce
> the annotated ServerEndpoints, it comes across while starting the server,
> in the catalina log?

No. That does not appear to be logged at any level.

What are you trying to achieve?

Mark


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

WebSockets

[Martin Funk]

Hi,

I'm into my first steps of using the WebSocket API.
Things are quite nice so far, WebSockets, used the right way, might open up
a complete new type of WebApplications.

I've got a question though, is there a way to configure Tomcat to announce
the annotated ServerEndpoints, it comes across while starting the server,
in the catalina log?

Have fun,

Martin

8.0.33 unencrypted websockets not generating correct HTTP CONNECT when using proxies?

[Rich Carreiro]

I am running Tomcat 8.0.33.  In my webapp I need to make outbound
websocket connections (i.e. be a client endpoint) through a HTTP proxy.

Outbound encrypted websockets (wss://foo.bar) work fine, but
unencrypted ones (ws://foo.bar) fail.

What I am seeing (in WsWebSocketContainer.createProxyRequest())
is that when there is no explicit port in the websocket URL, the container
does not put in an explicit port when building the CONNECT string.

So both ws://foo.bar and wss://foo.bar turn into
CONNECT foo.bar HTTP/1.1 [etc]

The proxy (reasonably, IMHO) assumes that a connect request
with no explicit port is going to port 443 on the destination host,
and thus the failure.  (And of course, if the proxy assumed no
explicit port meant port 80, then the problem would simply
be happening in the opposite way where ws:// would work
but wss:// would not).

If I add an explicit port to the ws:// URL (so ws://foo.bar:80) then
the websocket works fine through the proxy.

By contrast, Tyrus always puts an explicit port number in the
CONNECT request even when the ws:// and wss:// URLs do not
have explicit port numbers.

I've been looking at RFC 6455 and to my reading it says that a
websocket client should include the port when asking the proxy
to make a connection to the ultimate destination host.

Is this a known bug?  An acceptable difference in interpretation
of the RFC?

-- 
Rich Carreiro rlc...@gmail.com

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

Re: Tomcat 9.0.0M4 (and trunk) issue with Websockets (bug?)

[Mark Thomas]

On 05/04/2016 19:48, Mark Thomas wrote:
> On 04/04/2016 18:01, Francesco Bassi wrote:
>> Hello everybody.
>>
>> Tomcat 9 has a different behaviour than Tomcat 8, during the management of
>> MessageHandler.onMessage:
>>
>> - in Tomcat 8:
>>   Thread.currentThread().getContextClassLoader() returns an instance of
>> org.apache.catalina.loader.WebappClassLoader
>>
>> - in Tomcat 9
>>   Thread.currentThread().getContextClassLoader() returns an instance of
>> java.net.URLClassLoader
>>   (which doesn't resolve the WEB-INF/lib/* classes)
>>
>> It seems to be related to the switch to ParallelWebappClassLoader.
>> Is it a bug or and intended behaviour?
> 
> It looks like a bug. I need to dig deeper to figure out the root cause.

The root cause was the connector refactoring. This has been fixed in
9.0.x for 9.0.0.M5 onwards and 8.5.x for 8.5.1 onwards.

Mark


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

Re: Tomcat 9.0.0M4 (and trunk) issue with Websockets (bug?)

[Mark Thomas]

On 04/04/2016 18:01, Francesco Bassi wrote:
> Hello everybody.
> 
> Tomcat 9 has a different behaviour than Tomcat 8, during the management of
> MessageHandler.onMessage:
> 
> - in Tomcat 8:
>   Thread.currentThread().getContextClassLoader() returns an instance of
> org.apache.catalina.loader.WebappClassLoader
> 
> - in Tomcat 9
>   Thread.currentThread().getContextClassLoader() returns an instance of
> java.net.URLClassLoader
>   (which doesn't resolve the WEB-INF/lib/* classes)
> 
> It seems to be related to the switch to ParallelWebappClassLoader.
> Is it a bug or and intended behaviour?

It looks like a bug. I need to dig deeper to figure out the root cause.

Mark


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

Tomcat 9.0.0M4 (and trunk) issue with Websockets (bug?)

[Francesco Bassi]

Hello everybody.

Tomcat 9 has a different behaviour than Tomcat 8, during the management of
MessageHandler.onMessage:

- in Tomcat 8:
  Thread.currentThread().getContextClassLoader() returns an instance of
org.apache.catalina.loader.WebappClassLoader

- in Tomcat 9
  Thread.currentThread().getContextClassLoader() returns an instance of
java.net.URLClassLoader
  (which doesn't resolve the WEB-INF/lib/* classes)

It seems to be related to the switch to ParallelWebappClassLoader.
Is it a bug or and intended behaviour?

Thanks,

--fb

RE: [Bug 56301] Websockets not working after 8.0.0-RC10

[Caldarale, Charles R]

> From: Cyril Auburtin [mailto:cyril.aubur...@gmail.com] 
> Subject: Re: [Bug 56301] Websockets not working after 8.0.0-RC10

> Tomcat 8.0.0-RC10 is the stable version or is it 8.0.3?

No version of Tomcat 8 has been released as stable.  Look here:
http://tomcat.apache.org/whichversion.html
for the definitions of alpha, beta, and stable releases.  Note that release 
candidates are not releases, but just an early look at a forthcoming release 
(hence the use of the term "candidate").

 - 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

Re: [Bug 56301] Websockets not working after 8.0.0-RC10

[Cyril Auburtin]

Thanks Mark for your useful reply,
I thought the 8.0.1 version was supposed to be more stable than RCs? I'm
still not sure about what you said about it

I would first want to have an easy and stable servlet embedded server, it
could be tomcat, glassfish or any other. Once I have this, I would be glad
to take part in development
Tomcat 8.0.0-RC10 is the stable version or is it 8.0.3?

Thanks


2014-03-24 13:41 GMT+01:00 Mark Thomas :

> On 22/03/2014 19:15, Cyril Auburtin wrote:
> > Hi, thanks for your reply
> >
> > please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426with
> > the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378)
> > and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with
> tomcat
> > 8.0.0-RC10
> >
> > There's clearly a reply in the latter case.
> >
> > the version is the only thing changed between the 2 screenshots, I
> > carefully did mvn clean too
> > the code is here https://github.com/n11/mongo-cli-java it runs very
> simply
> > with tomcat embedded that you may know well
>
> Given that you are comparing an RC with an early beta release it isn't
> surprising that things might have changed.
>
> What have you done to investigate why the behaviour is different? Or are
> you expecting someone in this list to clone your app from GitHub and
> debug it for you?
>
> Have you compared your code with the various examples in Tomcat's unit
> tests to see if there are any obvious differences in how things are
> configured?
>
> How much have you researched how WebSocket Endpoints are deployed in
> Tomcat so you have a better idea of where to start looking from problems?
>
> Mark
>
>
>
> >
> >
> > 2014-03-22 19:20 GMT+01:00 Mark Thomas :
> >
> >> On 22/03/2014 16:17, Cyril Auburtin wrote:
> >>> Hi, this issue concerns the tomcat-embed server, (likely also the
> normal
> >>> tomcat server)
> >>> after version 8.0.1, websockets can't be estblished like before.
> >>>
> >>> I tried from a simple websocket example (standard java websocket
> >>> implemented in tomcat8
> >>> http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
> >>> and noticed it from my project https://github.com/n11/mongo-cli-java,
> >>> working untill apache version 8.0.0-RC10 (see pom.xml)
> >>>
> >>> It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
> >>>
> >>> screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423
> >>
> >> Which indicates your WebSocket request received a 404 response so this
> >> isn't a WebSocket problem at all.
> >>
> >> 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: [Bug 56301] Websockets not working after 8.0.0-RC10

[Mark Thomas]

On 22/03/2014 19:15, Cyril Auburtin wrote:
> Hi, thanks for your reply
> 
> please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426 with
> the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378)
> and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with tomcat
> 8.0.0-RC10
> 
> There's clearly a reply in the latter case.
> 
> the version is the only thing changed between the 2 screenshots, I
> carefully did mvn clean too
> the code is here https://github.com/n11/mongo-cli-java it runs very simply
> with tomcat embedded that you may know well

Given that you are comparing an RC with an early beta release it isn't
surprising that things might have changed.

What have you done to investigate why the behaviour is different? Or are
you expecting someone in this list to clone your app from GitHub and
debug it for you?

Have you compared your code with the various examples in Tomcat's unit
tests to see if there are any obvious differences in how things are
configured?

How much have you researched how WebSocket Endpoints are deployed in
Tomcat so you have a better idea of where to start looking from problems?

Mark



> 
> 
> 2014-03-22 19:20 GMT+01:00 Mark Thomas :
> 
>> On 22/03/2014 16:17, Cyril Auburtin wrote:
>>> Hi, this issue concerns the tomcat-embed server, (likely also the normal
>>> tomcat server)
>>> after version 8.0.1, websockets can't be estblished like before.
>>>
>>> I tried from a simple websocket example (standard java websocket
>>> implemented in tomcat8
>>> http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
>>> and noticed it from my project https://github.com/n11/mongo-cli-java,
>>> working untill apache version 8.0.0-RC10 (see pom.xml)
>>>
>>> It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
>>>
>>> screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423
>>
>> Which indicates your WebSocket request received a 404 response so this
>> isn't a WebSocket problem at all.
>>
>> 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: [Bug 56301] Websockets not working after 8.0.0-RC10

[Cyril Auburtin]

Thanks man you bombed my thread, from which I was already not expecting a
lot of answers, but well anyway..


2014-03-23 3:31 GMT+01:00 Hardik Vaishnav :

> Here is the example of what I am trying to do.
>
> JBoss Webserver Private IP : 192.168.10.100
> JBoss Webserver Public IP 172.x.x.x
>
> Server connected to Jboss: 192.168.10.101 & 192.168.10.102
>
> If I am on the Jboss machine I can access 192.168.10.101\abc\test.html
> If I am outside the network its not possible to access URL
> 192.168.10.101\abc\test.html
>
> To solve the problem I have PAC file as a proxy for my browser which
> redirect all request for 192.168.10.101 address to apache httpd proxy
> server which sits inside the (192.168.x.x) network.
>
> Upto this point everything works OK. Request comes to Apache httpd server
> but it is not able to pass the url as is to 192.168.10.101\abc\test.html
> and return the response back to the client.
>
> thanks,
> -Hardik
>
>
>
>
>
> On Sat, Mar 22, 2014 at 3:15 PM, Cyril Auburtin  >wrote:
>
> > Hi, thanks for your reply
> >
> > please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426with
> > the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378)
> > and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with
> tomcat
> > 8.0.0-RC10
> >
> > There's clearly a reply in the latter case.
> >
> > the version is the only thing changed between the 2 screenshots, I
> > carefully did mvn clean too
> > the code is here https://github.com/n11/mongo-cli-java it runs very
> simply
> > with tomcat embedded that you may know well
> >
> >
> > 2014-03-22 19:20 GMT+01:00 Mark Thomas :
> >
> > > On 22/03/2014 16:17, Cyril Auburtin wrote:
> > > > Hi, this issue concerns the tomcat-embed server, (likely also the
> > normal
> > > > tomcat server)
> > > > after version 8.0.1, websockets can't be estblished like before.
> > > >
> > > > I tried from a simple websocket example (standard java websocket
> > > > implemented in tomcat8
> > > > http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
> > > > and noticed it from my project https://github.com/n11/mongo-cli-java
> ,
> > > > working untill apache version 8.0.0-RC10 (see pom.xml)
> > > >
> > > > It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
> > > >
> > > > screenshot:
> https://issues.apache.org/bugzilla/attachment.cgi?id=31423
> > >
> > > Which indicates your WebSocket request received a 404 response so this
> > > isn't a WebSocket problem at all.
> > >
> > > Mark
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> >
>

Re: [Bug 56301] Websockets not working after 8.0.0-RC10

[Hardik Vaishnav]

Here is the example of what I am trying to do.

JBoss Webserver Private IP : 192.168.10.100
JBoss Webserver Public IP 172.x.x.x

Server connected to Jboss: 192.168.10.101 & 192.168.10.102

If I am on the Jboss machine I can access 192.168.10.101\abc\test.html
If I am outside the network its not possible to access URL
192.168.10.101\abc\test.html

To solve the problem I have PAC file as a proxy for my browser which
redirect all request for 192.168.10.101 address to apache httpd proxy
server which sits inside the (192.168.x.x) network.

Upto this point everything works OK. Request comes to Apache httpd server
but it is not able to pass the url as is to 192.168.10.101\abc\test.html
and return the response back to the client.

thanks,
-Hardik





On Sat, Mar 22, 2014 at 3:15 PM, Cyril Auburtin wrote:

> Hi, thanks for your reply
>
> please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426 with
> the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378)
> and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with tomcat
> 8.0.0-RC10
>
> There's clearly a reply in the latter case.
>
> the version is the only thing changed between the 2 screenshots, I
> carefully did mvn clean too
> the code is here https://github.com/n11/mongo-cli-java it runs very simply
> with tomcat embedded that you may know well
>
>
> 2014-03-22 19:20 GMT+01:00 Mark Thomas :
>
> > On 22/03/2014 16:17, Cyril Auburtin wrote:
> > > Hi, this issue concerns the tomcat-embed server, (likely also the
> normal
> > > tomcat server)
> > > after version 8.0.1, websockets can't be estblished like before.
> > >
> > > I tried from a simple websocket example (standard java websocket
> > > implemented in tomcat8
> > > http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
> > > and noticed it from my project https://github.com/n11/mongo-cli-java,
> > > working untill apache version 8.0.0-RC10 (see pom.xml)
> > >
> > > It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
> > >
> > > screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423
> >
> > Which indicates your WebSocket request received a 404 response so this
> > isn't a WebSocket problem at all.
> >
> > Mark
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: [Bug 56301] Websockets not working after 8.0.0-RC10

[Cyril Auburtin]

Hi, thanks for your reply

please see https://issues.apache.org/bugzilla/attachment.cgi?id=31426 with
the tomcat 8.0.1 (http://search.maven.org/#browse%7C-317025378)
and https://issues.apache.org/bugzilla/attachment.cgi?id=31427 with tomcat
8.0.0-RC10

There's clearly a reply in the latter case.

the version is the only thing changed between the 2 screenshots, I
carefully did mvn clean too
the code is here https://github.com/n11/mongo-cli-java it runs very simply
with tomcat embedded that you may know well


2014-03-22 19:20 GMT+01:00 Mark Thomas :

> On 22/03/2014 16:17, Cyril Auburtin wrote:
> > Hi, this issue concerns the tomcat-embed server, (likely also the normal
> > tomcat server)
> > after version 8.0.1, websockets can't be estblished like before.
> >
> > I tried from a simple websocket example (standard java websocket
> > implemented in tomcat8
> > http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
> > and noticed it from my project https://github.com/n11/mongo-cli-java,
> > working untill apache version 8.0.0-RC10 (see pom.xml)
> >
> > It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
> >
> > screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423
>
> Which indicates your WebSocket request received a 404 response so this
> isn't a WebSocket problem at all.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [Bug 56301] Websockets not working after 8.0.0-RC10

[Mark Thomas]

On 22/03/2014 16:17, Cyril Auburtin wrote:
> Hi, this issue concerns the tomcat-embed server, (likely also the normal
> tomcat server)
> after version 8.0.1, websockets can't be estblished like before.
> 
> I tried from a simple websocket example (standard java websocket
> implemented in tomcat8
> http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
> and noticed it from my project https://github.com/n11/mongo-cli-java,
> working untill apache version 8.0.0-RC10 (see pom.xml)
> 
> It seems there's a breaking change between 8.0.0-RC10 and 8.0.1
> 
> screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423

Which indicates your WebSocket request received a 404 response so this
isn't a WebSocket problem at all.

Mark


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

Re: [Bug 56301] Websockets not working after 8.0.0-RC10

[Cyril Auburtin]

Hi, this issue concerns the tomcat-embed server, (likely also the normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.

I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
and noticed it from my project https://github.com/n11/mongo-cli-java,
working untill apache version 8.0.0-RC10 (see pom.xml)

It seems there's a breaking change between 8.0.0-RC10 and 8.0.1

screenshot: https://issues.apache.org/bugzilla/attachment.cgi?id=31423


2014-03-22 13:15 GMT+01:00 :

> https://issues.apache.org/bugzilla/show_bug.cgi?id=56301
>
> Mark Thomas  changed:
>
>What|Removed |Added
>
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |INVALID
>
> --- Comment #3 from Mark Thomas  ---
> This looks like a configuration problem. Bugzilla is not a support forum.
> Please use the Tomcat Users mailing list.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

Re: Websockets timing out

[Bob Mancarella]

I didn't implement programmatic.


On Tue, Mar 4, 2014 at 3:52 PM, Mark Thomas  wrote:

> On 04/03/2014 20:50, David kerber wrote:
> > On 3/4/2014 3:46 PM, Bob Mancarella wrote:
> >> could you try this.
> >> http://dev.bizunite.com/inlook/echo.html
> >>
> >> click on annotation API then Connect and see if you stay connected.
> >
> > Seems to be working fine for me.
>
> I get an immediate close with the programmatic API but no issues with
> the annotation API.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Websockets timing out

[Bob Mancarella]

Ugh. Looks like I need to use wss in my environment. I just found this.

"If an encrypted WebSocket Secure connection (wss://) is used, then in the
case of transparent proxy servers, the browser is unaware of the proxy
server, so no HTTPCONNECT is sent. However, since the wire traffic is
encrypted, intermediate transparent proxy servers may simply allow the
encrypted traffic through, *so there is a much better chance that the
WebSocket connection will succeed if an encrypted WebSocket connection is
used.*"

Thanks everyone for your help.



On Tue, Mar 4, 2014 at 3:50 PM, David kerber  wrote:

> On 3/4/2014 3:46 PM, Bob Mancarella wrote:
>
>> could you try this.
>> http://dev.bizunite.com/inlook/echo.html
>>
>> click on annotation API then Connect and see if you stay connected.
>>
>
> Seems to be working fine for me.
>
>
>
>
>>
>> On Tue, Mar 4, 2014 at 3:44 PM, Mark Thomas  wrote:
>>
>>  On 04/03/2014 20:36, Bob Mancarella wrote:
>>>
 OK, this is strange. If I go here http://www.websocket.org/echo.html
 I get the same results. Click on Connect but don't hit Send and I get a
 Disconnected message soon after.
 If I use TLS it seems to work. If I hit Send immediately after Connect
 it
 seems to work.

 Anyone else seeing this?

>>>
>>> Not here.
>>>
>>> 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: Websockets timing out

[Mark Thomas]

On 04/03/2014 20:50, David kerber wrote:
> On 3/4/2014 3:46 PM, Bob Mancarella wrote:
>> could you try this.
>> http://dev.bizunite.com/inlook/echo.html
>>
>> click on annotation API then Connect and see if you stay connected.
> 
> Seems to be working fine for me.

I get an immediate close with the programmatic API but no issues with
the annotation API.

Mark


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

Re: Websockets timing out

[David kerber]

On 3/4/2014 3:46 PM, Bob Mancarella wrote:

could you try this.
http://dev.bizunite.com/inlook/echo.html

click on annotation API then Connect and see if you stay connected.


Seems to be working fine for me.





On Tue, Mar 4, 2014 at 3:44 PM, Mark Thomas  wrote:


On 04/03/2014 20:36, Bob Mancarella wrote:

OK, this is strange. If I go here http://www.websocket.org/echo.html
I get the same results. Click on Connect but don't hit Send and I get a
Disconnected message soon after.
If I use TLS it seems to work. If I hit Send immediately after Connect it
seems to work.

Anyone else seeing this?


Not here.

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: Websockets timing out

[Bob Mancarella]

could you try this.
http://dev.bizunite.com/inlook/echo.html

click on annotation API then Connect and see if you stay connected.


On Tue, Mar 4, 2014 at 3:44 PM, Mark Thomas  wrote:

> On 04/03/2014 20:36, Bob Mancarella wrote:
> > OK, this is strange. If I go here http://www.websocket.org/echo.html
> > I get the same results. Click on Connect but don't hit Send and I get a
> > Disconnected message soon after.
> > If I use TLS it seems to work. If I hit Send immediately after Connect it
> > seems to work.
> >
> > Anyone else seeing this?
>
> Not here.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Websockets timing out

[Mark Thomas]

On 04/03/2014 20:36, Bob Mancarella wrote:
> OK, this is strange. If I go here http://www.websocket.org/echo.html
> I get the same results. Click on Connect but don't hit Send and I get a
> Disconnected message soon after.
> If I use TLS it seems to work. If I hit Send immediately after Connect it
> seems to work.
> 
> Anyone else seeing this?

Not here.

Mark


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

Re: Websockets timing out

[Bob Mancarella]

OK, this is strange. If I go here http://www.websocket.org/echo.html
I get the same results. Click on Connect but don't hit Send and I get a
Disconnected message soon after.
If I use TLS it seems to work. If I hit Send immediately after Connect it
seems to work.

Anyone else seeing this?



On Tue, Mar 4, 2014 at 3:22 PM, Bob Mancarella  wrote:

> JSR356
>

Re: Websockets timing out

[Bob Mancarella]

JSR356

Re: Websockets timing out

[Mark Thomas]

On 04/03/2014 16:16, Bob Mancarella wrote:
> Tomcat 7.0.52 on Ubuntu 14.04
> 
> Websocket connection closes automatically after about 10 seconds. The
> browser creates the initial connection. OnOpen is called on the server.
> After 10 seconds OnClose is called and the connection is closed.
> I have tried changing connectionTimeout="-1" on Connector.
> Also tried session.setMaxIdleTimeout(-1); Neither has any effect.
> 
> On my Windows 7 dev machine the connection stays up until told to close.
> Also when I used apt-get to install Tomcat these files were missing...
> tomcat7-wobsocket.jar and websocket-api.jar. I copied them into
> /usr/share/tomcat7/lib which seemed to work.

Which WebSocket implementation are you trying to use? The JSR356 one or
the deprecated Tomcat proprietary one?

Mark

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

Re: Websockets timing out

[Bob Mancarella]

Thats the strange thing. The code isnt doing anything. It connects,
receives the onopen message and then the onclose with the 1006 return code
within a few seconds.



On Tue, Mar 4, 2014 at 3:04 PM, Bob Mancarella  wrote:

> More info.
> This is the return code to the browser
>  1006CLOSE_ABNORMAL *Reserved.* Used to indicate that a connection was
> closed abnormally (that is, with no close frame being sent) when a status
> code is expected.
>
>
> On Tue, Mar 4, 2014 at 2:41 PM, Bob Mancarella  wrote:
>
>> sorry, target is actually
>>
>> target = 'ws://' + window.location.host + '/inlook/websocket/
>> echoAnnotation ';
>>
>>
>

Re: Websockets timing out

[Bob Mancarella]

More info.
This is the return code to the browser
1006CLOSE_ABNORMAL*Reserved.* Used to indicate that a connection was closed
abnormally (that is, with no close frame being sent) when a status code is
expected.


On Tue, Mar 4, 2014 at 2:41 PM, Bob Mancarella  wrote:

> sorry, target is actually
>
> target = 'ws://' + window.location.host + '/inlook/websocket/
> echoAnnotation ';
>
>

Re: Websockets timing out

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bob,

On 3/4/14, 2:39 PM, Bob Mancarella wrote:
> Just using the EchoAnnotation code
> 
> ///
>
> 
// client code
> ///
>
> 
if (window.location.protocol == 'http:')
> { // target = 'ws://' + window.location.host + '../websocket/ 
> connect.ws'; target = 'ws://' + window.location.host +
> '/inlook/websocket/ connect.ws'; } else { target = 'wss://' +
> window.location.host + '../websocket/ connect.ws'; } if
> ('WebSocket' in window) { ws = new WebSocket(target); } else if
> ('MozWebSocket' in window) { ws = new MozWebSocket(target); } else 
> { alert('WebSocket is not supported by this browser.'); return; } 
> ws.onopen = function () { console.log('onopen'); }; ws.onmessage =
> function (event) { console.log('onmessage start'); }; ws.onclose =
> function () { console.log('onclose'); };
> 
> ///
>
> 
// server code
> ///
>
> 
@ServerEndpoint("/websocket/echoAnnotation")
> public class EchoMessage { @OnOpen public void onOpen(Session
> session) { System.out.println("New connection with client"); }
> 
> @OnMessage public void echoMessage(Session session, String msg) { 
> System.out.println("echoTextMessage: " + msg); }
> 
> @OnClose public void onClose(Session session) { 
> System.out.println("Close connection for client"); }
> 
> @OnError public void onError(Throwable exception, Session session) 
> { System.out.println("Error for client"); }
> 
> }

So both your client and server code do absolutely nothing. Where are
you actually sending a message? What events do you see occurring?

You are providing very little information, here.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFjGQAAoJEBzwKT+lPKRYrxAQAMeqEASzf5kjKeb8mA/G6PoC
4ZSlKEdzvHjZ6WogB2+zDsTrAB2qz7wkruCa+Vfwa1dEmbR+PgV96/PtfkrYyWrY
FR0Hq+sf2+tVHcAUiQEbo/g33UTVj4dGVJCcJkeinnsBIwHueH+nlielyYS1FGt1
BqFJ7AuC6GxrgDHrAm+fh+5wJGWPO2WxtMSRjEO4M0H/S7FCr+UqPlqrBpBwTKlc
UEuBCMfqzhdbRLpQciI7ZAaLN+8Wak4NyNp2e6+wr1WIRO9l3hlu8OYQYLTOCmm2
DfNG3oGWx3l9FZvnSq6GvJ96pw74G2TLSCaj9cGZL/BkCsWDTQvONVn/tmwKAuMh
FumyuqPhlVdnMLZBcd0MxCNbuY8MdY5G8Cda3KJtBsLtkwGUeifQVRrmKKOUJ9OS
79oSW2zmLs110XfTXgjYeGs4YMg7+WxNAHJzQmKuRcyKk3/9d2onv+4p9dwrmMy+
x1m8yR1YnPtkR2dI2BSZfdnPttWOsCLshmx2f1AaFA5VJ9XFC4Nb3bJxbSTBx52f
dap6urFuggIa9RKsHL3MDmL91U4gnuyTAbkAhapdpxTinQjpng+lBv07DGhCGIFc
/8B3zOrdgjB1VNJJmZPswdOLpdQpmVkHN3Gj5unT2lSzjv3Y6j+vxX0NbWkUU2Bj
TnakA5hZfnXWTnAaZ2Jx
=+Pb5
-END PGP SIGNATURE-

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

Re: Websockets timing out

[Bob Mancarella]

sorry, target is actually

target = 'ws://' + window.location.host +
'/inlook/websocket/echoAnnotation
';

Re: Websockets timing out

[Bob Mancarella]

Just using the EchoAnnotation code

///
// client code
///
if (window.location.protocol == 'http:')
{
// target = 'ws://' + window.location.host + '../websocket/
connect.ws';
target = 'ws://' + window.location.host + '/inlook/websocket/
connect.ws';
}
else
{
target = 'wss://' + window.location.host + '../websocket/
connect.ws';
}
if ('WebSocket' in window)
{
ws = new WebSocket(target);
}
else if ('MozWebSocket' in window)
{
ws = new MozWebSocket(target);
}
else
{
alert('WebSocket is not supported by this browser.');
return;
}
ws.onopen = function ()
{
console.log('onopen');
};
ws.onmessage = function (event)
{
console.log('onmessage start');
};
ws.onclose = function ()
{
console.log('onclose');
};

///
// server code
///
@ServerEndpoint("/websocket/echoAnnotation")
public class EchoMessage
{
@OnOpen
public void onOpen(Session session)
{
System.out.println("New connection with client");
}

@OnMessage
public void echoMessage(Session session, String msg)
{
System.out.println("echoTextMessage: " + msg);
}

@OnClose
public void onClose(Session session)
{
System.out.println("Close connection for client");
}

@OnError
public void onError(Throwable exception, Session session)
{
System.out.println("Error for client");
}

}


On Tue, Mar 4, 2014 at 2:29 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Bob,
>
> On 3/4/14, 11:16 AM, Bob Mancarella wrote:
> > Tomcat 7.0.52 on Ubuntu 14.04
> >
> > Websocket connection closes automatically after about 10 seconds.
> > The browser creates the initial connection. OnOpen is called on the
> > server. After 10 seconds OnClose is called and the connection is
> > closed. I have tried changing connectionTimeout="-1" on Connector.
> > Also tried session.setMaxIdleTimeout(-1); Neither has any effect.
>
> HttpSession has no impact on Websocket. Neither does
> connectionTimeout... that's all about HTTP connections, etc. Once you
> are in Websocket land, everything changes.
>
> Can you post some sample code -- like what your client and server code
> look like?
>
> > On my Windows 7 dev machine the connection stays up until told to
> > close. Also when I used apt-get to install Tomcat these files were
> > missing... tomcat7-wobsocket.jar and websocket-api.jar. I copied
> > them into /usr/share/tomcat7/lib which seemed to work.
>
> Please post your  configuration. Are you using APR at all?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTFimqAAoJEBzwKT+lPKRYnhAP/22raw7aVia8fEF9Sg9xANVV
> 0mYm/DoZWAY+xwN6TtHwiCHHXD1H0mfNXNpvcwBjVCheBPOdrrGAoJ+dg/w5BBey
> 98MaJ3aeyZ/J17wDW6ya3BgVomWkWOjDyqOtuMbOM8dZiCcOEwr/tqgQCnT5ClUH
> eqKPnZ4uRC5dx6+bpDkX2IzMZxKzPgdXV5b2n/k6ruGzarLbFCXtzyC4Jgi9wl1I
> 8a/1RwAAQSpRawEVjkHMhlzGUpHjRm/8m4HwZiVlRp6xWDn082Ag0DlcJODo5SH/
> ACOk0dH3oG/1QyRUxUWtlqMB5Be/34V8iomyo2GZAD3EvXurl8dpyc4FspU144sK
> m3hNwyYRtwbYjVplvbsCYAnVzLzY/I3FMt1Q0GFQLbs9pmY66RVVIelT/v5Dzd8s
> RS8Z0aZV6jSQIuYEfPzSmm///0TKVVKarGGpMeHzrw4wsRvkFnTCy2SvOundjqAa
> WzwCUCbFCjMPpp/mTVmU8xFFr1dkmsg1qsWz/mrk0ZK/f4ZSXP0eIK88gdi7NvXX
> lUJsntlEAmOzhBYP19G6qgicN4EQQa9qj7FWyzJg+dw7r/tWHBVp8zxCaGilv7He
> Ca2DacMamtq/fjyz5eyL9DNBZ6aEy4kk0xUWDATQAH0HdYD+/qg7iMs8gw9ASEfR
> Nt2GNqjUlcRBwLTML7bD
> =4vu+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Websockets timing out

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bob,

On 3/4/14, 11:16 AM, Bob Mancarella wrote:
> Tomcat 7.0.52 on Ubuntu 14.04
> 
> Websocket connection closes automatically after about 10 seconds.
> The browser creates the initial connection. OnOpen is called on the
> server. After 10 seconds OnClose is called and the connection is
> closed. I have tried changing connectionTimeout="-1" on Connector. 
> Also tried session.setMaxIdleTimeout(-1); Neither has any effect.

HttpSession has no impact on Websocket. Neither does
connectionTimeout... that's all about HTTP connections, etc. Once you
are in Websocket land, everything changes.

Can you post some sample code -- like what your client and server code
look like?

> On my Windows 7 dev machine the connection stays up until told to
> close. Also when I used apt-get to install Tomcat these files were
> missing... tomcat7-wobsocket.jar and websocket-api.jar. I copied
> them into /usr/share/tomcat7/lib which seemed to work.

Please post your  configuration. Are you using APR at all?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFimqAAoJEBzwKT+lPKRYnhAP/22raw7aVia8fEF9Sg9xANVV
0mYm/DoZWAY+xwN6TtHwiCHHXD1H0mfNXNpvcwBjVCheBPOdrrGAoJ+dg/w5BBey
98MaJ3aeyZ/J17wDW6ya3BgVomWkWOjDyqOtuMbOM8dZiCcOEwr/tqgQCnT5ClUH
eqKPnZ4uRC5dx6+bpDkX2IzMZxKzPgdXV5b2n/k6ruGzarLbFCXtzyC4Jgi9wl1I
8a/1RwAAQSpRawEVjkHMhlzGUpHjRm/8m4HwZiVlRp6xWDn082Ag0DlcJODo5SH/
ACOk0dH3oG/1QyRUxUWtlqMB5Be/34V8iomyo2GZAD3EvXurl8dpyc4FspU144sK
m3hNwyYRtwbYjVplvbsCYAnVzLzY/I3FMt1Q0GFQLbs9pmY66RVVIelT/v5Dzd8s
RS8Z0aZV6jSQIuYEfPzSmm///0TKVVKarGGpMeHzrw4wsRvkFnTCy2SvOundjqAa
WzwCUCbFCjMPpp/mTVmU8xFFr1dkmsg1qsWz/mrk0ZK/f4ZSXP0eIK88gdi7NvXX
lUJsntlEAmOzhBYP19G6qgicN4EQQa9qj7FWyzJg+dw7r/tWHBVp8zxCaGilv7He
Ca2DacMamtq/fjyz5eyL9DNBZ6aEy4kk0xUWDATQAH0HdYD+/qg7iMs8gw9ASEfR
Nt2GNqjUlcRBwLTML7bD
=4vu+
-END PGP SIGNATURE-

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

Re: Websockets timing out

[Bob Mancarella]

Besides what I mentioned where would i find that?


On Tue, Mar 4, 2014 at 1:54 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Bob,
>
> On 3/4/14, 1:15 PM, Bob Mancarella wrote:
> > Ubuntu 13.04 and Tomcat 8
> >
> > Same issue. Client makes the connection fine. Tomcat closes the
> > connection in 10 seconds.
>
> What's the client timeout on the server side? Perhaps you are...
> timing out.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTFiFrAAoJEBzwKT+lPKRY8/YQAIeHKuk+XbixExR5xgAZIqTN
> IouEC+qFsiw9KAwI5eTPjyLiGOvO6qxAwQgrfiQntoaDsdGot7ruqRn33lfLqtZR
> KL44Fy/gkkPDgcBeLwqDUU5gkcbcfWzT0gW6SGWLGV6C9ByOs0LVVpkPmKKBJqB5
> nbyr2LLbNuv5/4/JKKOSVgxx4IZO1nI3jrKeqnem3iRTwlTlxu6pCmr3XoETMPGn
> WykiuuVro74txdv2pM7nuJeoZpphjC260ZVHwv6xkGAOzvZP+yYI0Fb77uSegPLv
> rGgon5WIa3ubS5WeEwSvpeX+gwgRpV9s0n3/Jn6x+yYuj8gIDTOUVBduGxiFPfeF
> d2i2Mc0p0Hpsc13TDgLazMDhT3585Ut/M7QUEIyyTEQnE9U7mhma/tPkJ6nUahGk
> 9caL+AtZqH4LNaMQ2SL8HFnWpqzlpIPSX42jG7jPwcvTKE8JdrzlRY1kKPdbupAH
> f7XP3FF12uQkBvTcvBCUjQ+tfEVTcDyuBGzhKoxUMxArNGDYMfS+N9S+sjrm3Kw8
> Q1huNLAvUMsu5SWx2+Z8u5ezSgaAds/Zss+5rH3NdYNUpe80Kau5BS73oUNkpTyT
> vLMUv6rkuff4ftssCS8EHrjnrkWObsfOWzCUgqQelT+kMB8kXNoqGmQrsBC4LbcR
> NSWG46brPPG2vzUJf61r
> =v2j+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Websockets timing out

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bob,

On 3/4/14, 1:15 PM, Bob Mancarella wrote:
> Ubuntu 13.04 and Tomcat 8
> 
> Same issue. Client makes the connection fine. Tomcat closes the
> connection in 10 seconds.

What's the client timeout on the server side? Perhaps you are...
timing out.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFiFrAAoJEBzwKT+lPKRY8/YQAIeHKuk+XbixExR5xgAZIqTN
IouEC+qFsiw9KAwI5eTPjyLiGOvO6qxAwQgrfiQntoaDsdGot7ruqRn33lfLqtZR
KL44Fy/gkkPDgcBeLwqDUU5gkcbcfWzT0gW6SGWLGV6C9ByOs0LVVpkPmKKBJqB5
nbyr2LLbNuv5/4/JKKOSVgxx4IZO1nI3jrKeqnem3iRTwlTlxu6pCmr3XoETMPGn
WykiuuVro74txdv2pM7nuJeoZpphjC260ZVHwv6xkGAOzvZP+yYI0Fb77uSegPLv
rGgon5WIa3ubS5WeEwSvpeX+gwgRpV9s0n3/Jn6x+yYuj8gIDTOUVBduGxiFPfeF
d2i2Mc0p0Hpsc13TDgLazMDhT3585Ut/M7QUEIyyTEQnE9U7mhma/tPkJ6nUahGk
9caL+AtZqH4LNaMQ2SL8HFnWpqzlpIPSX42jG7jPwcvTKE8JdrzlRY1kKPdbupAH
f7XP3FF12uQkBvTcvBCUjQ+tfEVTcDyuBGzhKoxUMxArNGDYMfS+N9S+sjrm3Kw8
Q1huNLAvUMsu5SWx2+Z8u5ezSgaAds/Zss+5rH3NdYNUpe80Kau5BS73oUNkpTyT
vLMUv6rkuff4ftssCS8EHrjnrkWObsfOWzCUgqQelT+kMB8kXNoqGmQrsBC4LbcR
NSWG46brPPG2vzUJf61r
=v2j+
-END PGP SIGNATURE-

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

Re: Websockets timing out

[Bob Mancarella]

Ubuntu 13.04 and Tomcat 8

Same issue. Client makes the connection fine. Tomcat closes the connection
in 10 seconds.

Websockets timing out

[Bob Mancarella]

Tomcat 7.0.52 on Ubuntu 14.04

Websocket connection closes automatically after about 10 seconds. The
browser creates the initial connection. OnOpen is called on the server.
After 10 seconds OnClose is called and the connection is closed.
I have tried changing connectionTimeout="-1" on Connector.
Also tried session.setMaxIdleTimeout(-1); Neither has any effect.

On my Windows 7 dev machine the connection stays up until told to close.
Also when I used apt-get to install Tomcat these files were missing...
tomcat7-wobsocket.jar and websocket-api.jar. I copied them into
/usr/share/tomcat7/lib which seemed to work.

Re: Issue running Websockets JSR356 with Tomcat 7.0.50 Embedded

[Konstantin Kolinko]

2014-02-25 19:14 GMT+04:00 Jacopo Cappellato :
> Any hints? I would really appreciate if someone could provide some pointers 
> (e.g. classes involved etc) about the implementation of the mechanism used to 
> discover and deploy endpoints; I will then try to study the code in order to 
> figure out why it doesn't work when I set jarScanner.setScanClassPath(false)

The discovery is done with an SCI
(javax.servlet.ServletContainerInitializer), as defined in
tomcat7-websocket.jar/META-INF/services.  The class name is
"org.apache.tomcat.websocket.server.WsSci".
It seems that you prevented its discovery by skipping that jar in your
JarScanner.


You can also bootstrap web sockets by defining a listener in web.xml
(org.apache.tomcat.websocket.server.WsContextListener).
That listener just starts and shuts down the websocket engine, it does
not scan for endpoints.

http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/websocket/server/WsContextListener.html

Best regards,
Konstantin Kolinko

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