Re: HttpSessionBindingListener details
Right, makes sense. Thank you. On Thu, Feb 5, 2015 at 10:21 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-05 21:07 GMT+03:00 Igor Urisman igor.uris...@gmail.com: Hello, folks. I can't seem to find a good solution for the following problem. I have an object that is added to the HTTP session via the setAttribute() method. The object implements the HttpSessionBindingListener interface and its valueUnbound() method is dutifully called by the contained at the time the session is destroyed. Now, in my use case the session is destroyed via the HttpSession.invalidate() call, so (presumably) the container creates the new session concurrently with destroying the current session. No. invalidate() only destroys the current session. It does not create any new sessions. A new session can be created by a HttpServletRequest.getSession() / getSession(true) call. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
HttpSessionBindingListener details
Hello, folks. I can't seem to find a good solution for the following problem. I have an object that is added to the HTTP session via the setAttribute() method. The object implements the HttpSessionBindingListener interface and its valueUnbound() method is dutifully called by the contained at the time the session is destroyed. Now, in my use case the session is destroyed via the HttpSession.invalidate() call, so (presumably) the container creates the new session concurrently with destroying the current session. What I need is preserve the object across the session destruction event. In other words, I want it to be rebound to the new session. Is there a way to do that from inside the valueUnbound() call? All I get there is the the HttpSessionBindingEvent object, passed passed as an argument, but its getSession() method returns the old session that is in the final stages of being destroyed. I wonder if this isn't a bug and if it wasn't meant to return the new session, for what's the point giving me the old session — it's easy for me to get to it anyway, and its state is already invalid. Many thanks in advance, -Igor.
Re: Java to JavaScript RMI framework available.
Johan, On Thu, Jan 2, 2014 at 1:25 AM, Johan Compagner jcompag...@servoy.comwrote: does it also do the other way around? So also having the endpoint on the server that has methods that can be called from javascript in a very easy way? It doesn't. There is already a mechanism that sits above simple message passing, for calling into the server: XMLHttpRequest, aka AJAX. Competing with that would have taken more thought and effort that so far I have been able to put into FERMI. I imagine that if this gets some acceptance, offering a fully symmetric RMI may become a viable idea. Not on the immediate roadmap, though. -Igor. On 31 December 2013 01:55, Igor Urisman igor.uris...@gmail.com wrote: Folks, I needed to write this for something I am working on and thought there might be a wider audience for it. Tomcat 8 supports standard compliant Websockets, which provide convenient asynchronous full-duplex server to client data transport. The framework I am offering builds on top of that a feature rich remote method invocation paradigm. Please check it out. https://github.com/iurisman/FERMI Apache 2.0 license. Happy coding. Igor. -- Johan Compagner Servoy
Java to JavaScript RMI framework available.
Folks, I needed to write this for something I am working on and thought there might be a wider audience for it. Tomcat 8 supports standard compliant Websockets, which provide convenient asynchronous full-duplex server to client data transport. The framework I am offering builds on top of that a feature rich remote method invocation paradigm. Please check it out. https://github.com/iurisman/FERMI Apache 2.0 license. Happy coding. Igor.
Re: Minor grammar glitch in a Websocket exception message.
Precisamente. On Fri, Dec 13, 2013 at 3:11 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/12/13, 4:43 PM, Mark Thomas wrote: On 12/12/2013 06:35, Igor Urisman wrote: As seen in 8.0.0 RC5: java.lang.IllegalStateException: javax.websocket.DeploymentException: Multiple Endpoints may not be deployed to using the same path [/conntestCloseEndpoint] IMHO, the message can't make up its mind between to the same path and using the same path. While I think the grammar of the original is technically OK Split infinitive? The original verb appears to be to deployed (deployed-to) and used as if endpoints were deployed to something. Are they deployed /to/ a path, or /using/ a path? I'm guessing ... both. :) Perhaps the best phrasing is to say something like Endpoint path [path] is already bound [other endpoint details?]. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSq5Q6AAoJEBzwKT+lPKRYL18P/A483rHy6sl7u1cmWkKgib/a f9JFddHLpKg+yzKegQ7bvJNmzEjjplGKqSGIV6EgKrsBEnezafEkVIp5uidc/5TH A0N+6go0N3O3GtnjjtrXivbVz+SMni09avXnz1T1RB6z0drN7JgYZ2SGfN+NDDIA /5eIpfinl4m/0cfZHfUVygy5U2liGLJ8a0bfrBLc1Oab4Tc0ZzzTcque/plnkjLu ICcGpWd6k6b1SdTpavLQXnz9aT/puVdvtmFPkMDMI7rSiUJbNJ+U15IPtPRwzmYC P8UM9jBYkf00yuxvSovGOEnC3FiUmOVULUlWgkV/5ipg0GldjpFBSblClQXQOhGT xsqcYfxW4LhqFCUMhVAeQHXmAw7c+/Pg/jEn6zh/NGIwQ6MfQiK7vEfZUKwg3YVj hIrPgJHXzPCenjV6lxdY9HD/xtt3azYdgEaw5w+K5cftn1LW2+X6/VhLyS51a97P NIWUv+zg+3Euy4eisfYDczMZdAr/gc4HsJioaboeC3EnatwC1qyGa1zCGyodg25R jR6l7tjiyDNpfbMmPTEF5ql/dOnCc378fbiBR2WngTLIa2I76VBkK1rpKcuvntSd NXst7kr1bW34y/jND3e7uzhZfPiZopPnmQ7biUX4AGQAg3FtoivRUNDVJqAqOXuh JX0SvUCE37b1XG4JWGRB =jLyk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Minor grammar glitch in a Websocket exception message.
As seen in 8.0.0 RC5: java.lang.IllegalStateException: javax.websocket.DeploymentException: Multiple Endpoints may not be deployed to using the same path [/conntestCloseEndpoint] IMHO, the message can't make up its mind between to the same path and using the same path. -Igor.
Re: setting the text or binary buffer size for websockets
Upgraded my environment to 8RC5 and this feature works for me. Don't know how much help this is, but here's my deployment descriptor: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 display-nameFERMI Framework Test Application/display-name context-param param-nameorg.apache.tomcat.websocket.textBufferSize/param-name param-value10240/param-value /context-param /web-app -Igor. On Sun, Nov 17, 2013 at 7:15 AM, Johan Compagner jcompag...@servoy.comwrote: Exactly which version of Tomcat 7 are you using? currently testing it on 8 RC5 I can test on 7, but i guess thats the +/- the same code? Latest 8 RC is fine but then why are you looking at the Tomcat 7 docs? first that i found, and also this http://tomcat.apache.org/tomcat-8.0-doc/web-socket-howto.html is the same i will look at it a bit more then, but for my current tests it didn't have any effect as far as i could see.
Re: setting the text or binary buffer size for websockets
Johan, What you've described is exactly what works for me. But I am still on RC1. -Igor. On Sat, Nov 16, 2013 at 6:12 AM, Johan Compagner jcompag...@servoy.comwrote: sorry, mail did go to soon... I do this in the web.xml (directly in the web-app tag) context-param param-nameorg.apache.tomcat.websocket.textBufferSize/param-name param-value32768/param-value /context-param context-param param-nameorg.apache.tomcat.websocket.binaryBufferSize/param-name param-value32768/param-value /context-param But this doesn't seem to have any effect, i still see in the browser stuff like frames of max 8192 (and continuation frames) We have problems (with chrome) with all kinds of errors when sending these frames (invalid opcode, utf char encoding problem, reserved words 1 ,2 ,3 errors in the browser) So i want to see if i just don't use frames what the result is then Johan On 16 November 2013 15:09, Johan Compagner jcompag...@servoy.com wrote: Hi i read this: http://tomcat.apache.org/tomcat-7.0-doc/web-socket-howto.html so what i do is add this into the web.xml -- Johan Compagner Servoy -- Johan Compagner Servoy
Re: Servlet init method called multiple times
Print the call stack from a subsequent init()? On Wed, Oct 23, 2013 at 8:33 AM, Richard Pierce rpie...@empoweredbenefits.com wrote: Hey Chris. I wish it was, that would be an easy fix. It's not- grepped the whole codebase for it, and visually inspected these servlets. -Richard On 10/23/13 11:27 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Richard, On 10/22/13 6:57 PM, Richard Pierce wrote: The init() method of all of my servlets is being called every 10 seconds or so. I verified this by adding a System.out to the init() methods of my servlets. However, the server is not restarting- just init gets recalled, even with no load on the box at all. I have no idea where to begin debugging this, but it does appear to be affecting performance. The API states The servlet container calls the init method exactly once after instantiating the servlet. I added an instance and static variable to the servlet, to see whether the init method was being called multiple times on the same instance or if new instances were being created. Initialized: 1 times (local), 28 total (static); Thead=http-127.0.0.1-51443-1 Time: Tue Oct 22 18:40:36 EDT 2013 Initialized: 1 times (local), 29 total (static); Thead=http-127.0.0.1-51443-1 Time: Tue Oct 22 18:40:41 EDT 2013 Initialized: 1 times (local), 30 total (static); Thead=http-127.0.0.1-51443-1 Time: Tue Oct 22 18:40:46 EDT 2013 Initialized: 1 times (local), 31 total (static); Thead=http-127.0.0.1-51443-1 Time: Tue Oct 22 18:40:51 EDT 2013 Obviously it is happening every 5 seconds, but WHAT is happening? Tomcat version: Apache Tomcat/6.0.35 OS: Linux version 2.6.18-194.11.3.el5 Is your servlet perhaps using SingleThereadModel? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSZ+rsAAoJEBzwKT+lPKRYlcIP/23Ch7Hien8CDbDM86vZmqBo yjPMk+2Sc5AV2bH5pwUw3QHhU6bHBQ8m56cTKwKceuiR3fWgHXhZ7hDvbEoO txLMJkEf71+g7vk435MXiRJgf8UrbDVncLI7hlWiAnOQAgbQHCM9+DHU1pdYdkSa qFOk+cPOqY32yJaRa+RJNPuel/9bwXV32E5nTX8xejvq5XeKlJMEgRtRbbN0IoIt hOAjJ9kODYPuq4pSpyvtaHIpBC1m8D9voqLRZgL5yn0TSXUKT/tw59MD8P5MnuRi id1mBtAMMsEglpimKGfhGwcrQ3DoDl10ykKQe7dTt/WySveusolzD5UngH5nxXBl cjpscCN6SuRA7ndSnXxvd6xMYykBiZViYcFCDBY+dWANFmdKgLwBwxj9u1AnV49k 2DyU/r/QiweLj6mEsoJs/WORnkUflnDiUKo6YT/TOW05GdajcoCF9ONVYx+QJ/co viJAzh2r0fm5Nw1xBiOc0O1wiu51LLnWKzr9ptkD7uEro9D4dWSzL6yWbhIJlyEE 2F8eMOC4ZhxK6EnBYsFA9G9uL5gjXoGKugJlfNpYy9SL5sleB0EMvya8tfMKaCUy yjVprnEAG48/xobyiBhZP86QUYHHFX9siXCz97/7Vk+lxX5VXZN654pq92B6JJGI Hhugrhw8a79zq9+zbiIF =bdUq -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: WebSocket message size limits
You're right, Nikki,-- he has. There was a point to all this in the beginning but I think it's all good now. All seems to work as advertized. I went back to some earlier test cases and what I thought was failing is in fact working fine. -Igor. On Mon, Sep 23, 2013 at 11:56 PM, Niki Dokovski nick...@gmail.com wrote: On Tue, Sep 24, 2013 at 8:15 AM, Igor Urisman igor.uris...@gmail.com wrote: Thanks again, Mark, for the quick turnaround. Which of the 5 parameters on this page would be responsible for changing the 125-byte max whole text message size? Mark did a great job describing the properties and if it's still unclear looking at the origins is always an option. 125 sizing is for the control frames [1]. The internal buffers for text and binary frames are 8k. Respective sizes are subject to configuration by org.apache.tomcat.websocket.textBufferSize and org.apache.tomcat.websocket.binaryBufferSize Cheers Niki [1] http://tools.ietf.org/html/rfc6455#section-5.5 -Igor. On Mon, Sep 23, 2013 at 9:07 AM, Mark Thomas ma...@apache.org wrote: On 23/09/2013 08:44, Igor Urisman wrote: Thanks for the speedy reply, Mark. I have thought about that code for a minute. You're right; what it does is construct the entire message in memory. My use case has no use for partials and the message sizes are tens to hundreds of Kb. Didn't mean to defeat anything there, just the use case. If there is a way to change the default min size of a whole message, that would certainly be the way to go,---another right for you. There's only one problem: I don't know how. Do you? See the Tomcat 8 WebSocket docs for details: http://tomcat.apache.org/tomcat-8.0-doc/web-socket-howto.html Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket message size limits
Thanks for the speedy reply, Mark.
I have thought about that code for a minute. You're right; what it does is
construct the entire
message in memory. My use case has no use for partials and the message
sizes are
tens to hundreds of Kb. Didn't mean to defeat anything there, just the use
case.
If there is a way to change the default min size of a whole message, that
would certainly be
the way to go,---another right for you. There's only one problem: I don't
know how.
Do you?
-Igor.
On Mon, Sep 23, 2013 at 3:39 AM, Mark Thomas ma...@apache.org wrote:
On 22/09/2013 21:49, Igor Urisman wrote:
However, the server implementation is free to pick the maximum size of a
payload
that it is willing to receive as a whole. Tomcat designers chose that
size
to be 125
bytes. Reasonable number given the particulars of the wire level
protocol,
but not
one defined in the standard.
That statement not correct. The default incoming buffer size for text
and binary messages is 8k bytes. This applies to both the client and the
server.
There is a specification (RFC6455) mandated limit on control message
payloads of 125 bytes.
It appears that there's also a talk of exposing the inbound message via a
Reader
http://www.oracle.com/technetwork/articles/java/jsr356-1937161.htmlbut
that's not in Java EE 7.
Another incorrect statement. MessageHandler.WholeReader is supported
in JSR-356. Note that Readers only work with whole messages, not partial
ones.
So, just as a specific example, my implementation looks like the
following:
public class FermiMessageHandler implements
MessageHandler.PartialString {
private Session session;
private int maxMessageSize = 2;
private StringBuilder messageBuffer = new
StringBuilder(maxMessageSize);
FermiMessageHandler(Session session) {
this.session = session;
}
@Override
public void onMessage(String msgPart, boolean last) {
if( messageBuffer.length() + msgPart.length() maxMessageSize) {
session.close(new
CloseReason(CloseReason.CloseCodes.CLOSED_ABNORMALLY, Message is too
long);
}
else {
messageBuffer.append(msgPart);
if (last) {
String message = messageBuffer.toString();
// We have a complete message. Do something with it.
messageBuffer.setLength(0);
}
}
}
}
Just think about what you have done for a minute. The whole point of
partial messages is so that you don't have to buffer the entire message
in memory before processing it. Your code defeats the point of that
entirely. You'd be better off increasing the maximum message size
supported by the implementation and using MessageHandler.WholeString.
Better still would be to re-write your handler so it actually processed
partial messages.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket message size limits
Thanks again, Mark, for the quick turnaround. Which of the 5 parameters on this page would be responsible for changing the 125-byte max whole text message size? -Igor. On Mon, Sep 23, 2013 at 9:07 AM, Mark Thomas ma...@apache.org wrote: On 23/09/2013 08:44, Igor Urisman wrote: Thanks for the speedy reply, Mark. I have thought about that code for a minute. You're right; what it does is construct the entire message in memory. My use case has no use for partials and the message sizes are tens to hundreds of Kb. Didn't mean to defeat anything there, just the use case. If there is a way to change the default min size of a whole message, that would certainly be the way to go,---another right for you. There's only one problem: I don't know how. Do you? See the Tomcat 8 WebSocket docs for details: http://tomcat.apache.org/tomcat-8.0-doc/web-socket-howto.html Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebSocket message size limits
Mark,
Sorry for the delay in responding. I am working on this project in my spare
time.
That I was missing something wasn't the question. The question was what.
I think I figured it out, but wanted to follow up for two reasons. One is
the benefit of
others in my situation (this stuff is still pretty sparsely documented) and
two, there are
some further points that I am still not sure about and hope someone could
comment on.
Because of security concerns, the transmission of large messages over a
WebSocket
has different semantics for in- (from client to server) and out-bound (from
server to
client) messages. Since it is up to the client to establish a WebSocket
session, the
server is free to send a message of any size by simply calling
javax.websocket.RemoteEndpoint.sendText(String message)
I imagine client implementations may differ in how they deal with
particularly large
payloads, but anything reasonable will be transmitted and received just
fine and at
lest as defined by the JSR 356, sizes of up to unsigned long are supported.
The same is not the case for the inbound messages. And the way Tomcat
handles
large messages is neither standard, nor at this point (well) documented.
Here's what
I have discovered:
The websocket.send(String) method takes a payload of any size. (There may
be further nuances in cases when client generates inbound traffic faster
than the
network is able to transmit it, but at least when bufferedAmount == 0, this
statement is
true.)
However, the server implementation is free to pick the maximum size of a
payload
that it is willing to receive as a whole. Tomcat designers chose that size
to be 125
bytes. Reasonable number given the particulars of the wire level protocol,
but not
one defined in the standard.
In other words, if I want to receive inbound message that can be longer
than 125
bytes, I need to configure the server side session with a message handler
that
implements
javax.websocket.MessageHandler.Partial
The implementation will partition the message into fragments of up to 8192
characters
and make them available to the app code via the implementation of
onMessage(String part, boolean last) method.
It appears that there's also a talk of exposing the inbound message via a
Reader http://www.oracle.com/technetwork/articles/java/jsr356-1937161.htmlbut
that's not in Java EE 7.
So, just as a specific example, my implementation looks like the following:
public class FermiMessageHandler implements MessageHandler.PartialString {
private Session session;
private int maxMessageSize = 2;
private StringBuilder messageBuffer = new StringBuilder(maxMessageSize);
FermiMessageHandler(Session session) {
this.session = session;
}
@Override
public void onMessage(String msgPart, boolean last) {
if( messageBuffer.length() + msgPart.length() maxMessageSize) {
session.close(new
CloseReason(CloseReason.CloseCodes.CLOSED_ABNORMALLY, Message is too
long);
}
else {
messageBuffer.append(msgPart);
if (last) {
String message = messageBuffer.toString();
// We have a complete message. Do something with it.
messageBuffer.setLength(0);
}
}
}
}
Thanks,
-Igor.
On Wed, Sep 18, 2013 at 1:12 AM, Mark Thomas ma...@apache.org wrote:
On 18/09/2013 06:19, Igor Urisman wrote:
Dear All,
I am looking for help in understanding why the size of the inbound
WebSocket message is limited to 125 bytes.
It isn't, at least not by Tomcat.
I realize that this may not
even be the right place for my question, but am still hoping for a clue.
From looking at the RFC 6455, Sec. 5.2 Base Framing Protocol, I am making
two conclusions:
1. There's nothing in it to suggest a payload length asymmetry between
inbound and outbound messages. Yet, although I am able to send very
large
messages to the browser, an attempt to send anything over 125 bytes
results
in error and a connection shutdown. (I tried FF and Chrome on a Mac).
2. It's easy to see from the wire protocol why 125 is the simplest
payload
length but other sizes up to unsigned 64 bit int are supported. So,
browser's failure to transmit more than 125 bits indicates both, the most
restrictive payload size AND lack of support for fragmented messages.
The error that FF gives reads The decoded text message was too big for
the
output buffer and the endpoint does not support partial messages which
to
me reads like they are saying that Tomcat did not indicate during
handshake
that it accepts multi-part messages. True?
False. There is nothing in the handshake that allows one end not to
support multi-part messages nor to limit the maximum message length.
That looks like a client side issue to me. Maybe you need to make the
client side output buffer bigger.
Tomcat's web socket support (client and server) has been tested
WebSocket message size limits
Dear All, I am looking for help in understanding why the size of the inbound WebSocket message is limited to 125 bytes. I realize that this may not even be the right place for my question, but am still hoping for a clue. From looking at the RFC 6455, Sec. 5.2 Base Framing Protocol, I am making two conclusions: 1. There's nothing in it to suggest a payload length asymmetry between inbound and outbound messages. Yet, although I am able to send very large messages to the browser, an attempt to send anything over 125 bytes results in error and a connection shutdown. (I tried FF and Chrome on a Mac). 2. It's easy to see from the wire protocol why 125 is the simplest payload length but other sizes up to unsigned 64 bit int are supported. So, browser's failure to transmit more than 125 bits indicates both, the most restrictive payload size AND lack of support for fragmented messages. The error that FF gives reads The decoded text message was too big for the output buffer and the endpoint does not support partial messages which to me reads like they are saying that Tomcat did not indicate during handshake that it accepts multi-part messages. True? I can't speak for others, but for my project 125 bytes is unacceptably small. So, fundamentally what I need to know is this: do I need to implement my own fragmenting or am I missing something? Many thanks in advance, -Igor.
8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Dear all,
It appears that if I obtain the ServletContext object via Spring's
WebApplicationInitializer
mechanismhttp://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html,
it is not yet seeded with the WebSocket ServerContainer object.
Alternatively, if I use straight up ServletContextListener, all's good.
More specifically, this works:
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
@WebListener
public class ServletBootstrapper implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// NO-OP
}
}
But this doesn't:
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import org.springframework.web.WebApplicationInitializer;
public class SpringBootstrapper implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext sc) throws ServletException {
// Next line returns null
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
}
I verified that the ServletContext object returned in both is the same, so
that part is good.
I imagine the root cause is that Spring uses an earlier container event to
post implementations of the WebApplicationInitializer interface, before the
ServerContainer attribute is set by the WebSocket code. Given the ubiquity
of Spring, this may prove problematic.
Many thanks,
-Igor.
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
I couldn't agree more. WebSocket is provided by the container. But the time any app code gets to run, Spring of Fall, container ought to be done. -Igor. On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 9/13/13 7:50 AM, Konstantin Kolinko wrote: I see no issue here, as both WebSocket implementation and Spring's WebApplicationInitializer rely on use of javax.servlet.ServletContainerInitializer to initialize themselves. Reading the Servlet specification 3.1, I see no words in the specification on the ordering of ServletContainerInitializer instances. (It would be reasonable that they were covered by ch. 8.2.2 Ordering of web.xml and web-fragment.xml, but I see no explicit wording there). The fact that Tomcat uses an SCI is an implementation detail, so I'm not sure the spec is relevant. I think it's reasonable for an SCI to expect that the environment Tomcat provides is available without having to resort to implementation-specific hacks like re-ordering their own SCIs with respect to Tomcat's. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSM02MAAoJEBzwKT+lPKRYEuQP/3OK1OZj4LGRTl8PlkVZ/VQ2 gWEpIeLmXAxmr4WIO666dtd/BhcB1oLc2TXkqMMmThnYO4u8wl0nlFh8IlIk4y2z /2OPbyd4tUhpvhk5R63xFqifbyKXFnvQVAeFlc9KdAhJ61TYGjJbNF6sUCY65Sa2 e6kvhoTCx/E8LuoBOsQwuQo/tcpZZfXrwqtF1EQj/8imWhnM8eKjvD+TtaNtVKFj kL5Vf4gL2ti3U9EVtlqEF+ul4AEnTWCw9nZukv+mbRlMe157LIKd0aY0y3Kft4D3 3tVdp5TuB8T+grycrkENr8g/AyPPnaUD/tkLTkSeQQDWbxufMTSIsamEkPLVioXG I19N0eetB0CnRu0moO9PINEGHcEEFkCUGi0yG8x+LKpQ0nqG6eTeBM2VFolX1dur h1a0RWqnCqu/bSv3U3psDZofxLYpDrAOCESNXUFhowMRswhS5zrkihN42YKWJ6FN 1/RUlhHB2msf/UbAK+WDhQbqf5yhgBP0871pUfWh4VdQdUWFmyIRltNqt8aDtTJ1 p/XoWTkMEeCQLDpA2S1iLdkHKfUGAOycjak6qa+6552k42nErsHDaMZ0dagYO4dv BiRQdLp0T3Kcfrjpr9DjKOgmk7aBnAgKLGMNBD2MT4Tir8QCnRrGIYTtBRpBXG+q aECZxgxMa8mdQWNQQ0Cj =UJf1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0-RC1: WebSocket Exception
Right on. Thank you both, Mark and Niki. -Igor. On Sun, Sep 1, 2013 at 3:00 AM, Mark Thomas ma...@apache.org wrote: On 31/08/2013 02:40, Igor Urisman wrote: That's correct. I call close() inside onOpen(). You correctly call onClose() on the endpoint as well, so my code is happy. But a thread of yours crashes milliseconds later. I have no problem changing my code to call close() after onOpen() returns, of course. But if you insist on this semantics, perhaps you ought to throw an exception in my thread when I call close() inside onOpen()? No need to change your code. This has already been fixed in trunk and will be included in 8.0.0-RC2. RC2 has been delayed because it needs a tc-native release to fix a non-blocking IO issue with the APR/native connector that can result in corruption of responses. The 1.1.28 release of tc-native should happen this week. The 7.0.43 and 8.0.0-RC2 releases will follow shortly afterwards. Mark Thanks! -Igor. On Fri, Aug 30, 2013 at 6:12 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Aug 31, 2013 at 12:33 AM, Igor Urisman igor.uris...@gmail.com wrote: Dear all, Getting the following exception with none of my code on the stack: SEVERE: Error reading request, ignored java.lang.IllegalStateException: The WebSocket session has been closed and no method (apart from close()) may be called on a closed session at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:607) at org.apache.tomcat.websocket.WsSession.getUserPrincipal(WsSession.java:536) at org.apache.tomcat.websocket.server.WsServerContainer.registerSession(WsServerContainer.java:308) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:131) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) May still be my problem, of course, but far as I can tell, all I do is call Session.close() once on this session. I understand this may be too little to go by,-- if so I am happy to try and isolate into a testcase. Do you call close during @OnOpen? This exception here is possible in this case as register session call is done after invkoing applicaiton ep OnOpen? Thanks in advance, -Igor. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
8.0.0-RC1: WebSocket Exception
Dear all, Getting the following exception with none of my code on the stack: SEVERE: Error reading request, ignored java.lang.IllegalStateException: The WebSocket session has been closed and no method (apart from close()) may be called on a closed session at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:607) at org.apache.tomcat.websocket.WsSession.getUserPrincipal(WsSession.java:536) at org.apache.tomcat.websocket.server.WsServerContainer.registerSession(WsServerContainer.java:308) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:131) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) May still be my problem, of course, but far as I can tell, all I do is call Session.close() once on this session. I understand this may be too little to go by,-- if so I am happy to try and isolate into a testcase. Thanks in advance, -Igor.
Re: 8.0.0-RC1: WebSocket Exception
That's correct. I call close() inside onOpen(). You correctly call onClose() on the endpoint as well, so my code is happy. But a thread of yours crashes milliseconds later. I have no problem changing my code to call close() after onOpen() returns, of course. But if you insist on this semantics, perhaps you ought to throw an exception in my thread when I call close() inside onOpen()? Thanks! -Igor. On Fri, Aug 30, 2013 at 6:12 PM, Niki Dokovski nick...@gmail.com wrote: On Sat, Aug 31, 2013 at 12:33 AM, Igor Urisman igor.uris...@gmail.com wrote: Dear all, Getting the following exception with none of my code on the stack: SEVERE: Error reading request, ignored java.lang.IllegalStateException: The WebSocket session has been closed and no method (apart from close()) may be called on a closed session at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:607) at org.apache.tomcat.websocket.WsSession.getUserPrincipal(WsSession.java:536) at org.apache.tomcat.websocket.server.WsServerContainer.registerSession(WsServerContainer.java:308) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:131) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) May still be my problem, of course, but far as I can tell, all I do is call Session.close() once on this session. I understand this may be too little to go by,-- if so I am happy to try and isolate into a testcase. Do you call close during @OnOpen? This exception here is possible in this case as register session call is done after invkoing applicaiton ep OnOpen? Thanks in advance, -Igor.
A Couple of 8.0.0 WebSocket Questions
Dear all, 1. I see how to close a session from either end of the connection. That, of course, leaves the underlying endpoint intact. Is there a way to un-deploy an entire server endpoint so that no new connections can be made to it? If so, will it close existing sessions? 2. Is there a way to query the ServerContainer for deployed endpoints? I'd like to do that to check that there isn't already one at a given path. The only solution I've found so far is to try to deploy it and, if the generic DeploymentException is thrown, parse the error message. Not great. 3. What's the recommended way of binding an HTTP session to a Websocket one? I was able to get this to work by using a custom ServerEndpointConfig.Configurator class that augments the base modifyHandshake() method by stashing the HTTP session in a ThreadLocal variable. Seems like the linkage between the WebSocket session and the HTTP session is so basic that perhaps there's a more straightforward way to do this? Many thanks in advance and apologies if this has been covered on this list or I'm overlooking it in the docs. -Igor.
Re: 8.0.0 Problems With javax.websocket.*
Martin, I can't because the mailing list will strip the attachment. Please suggest a way to submit a case. -Igor. On Tue, Aug 6, 2013 at 12:21 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Igor, Send this message to Tomcat's users mailing list. On Tue, Aug 6, 2013 at 9:05 PM, Igor Urisman igor.uris...@gmail.comwrote: Martin, I've attached a simple WSPILOT webapp where I attempted to use both programmatic and annotational server endpoints. It's very simple and reduced to just a few lines of code on client and server, so I hope it'll be easy to follow. SERVER code consists of two small classes: 1. Annotational configures annotation configured endpoint at /ant. Ready to use. 2. Programmatic is a programmatically configured endpoint at /pgm. Requires boostrappinig. CLIENT: 1. When you hit the app, index.jsp is tri. 2. Java scriplet bootstraps the programmatic endpoint at /pgm. 3. Inline JavaScript attempts to connect to connect to the above endpoints. PROBLEM: 1. I am able to connect to the annotational endpoint, but ws.send (line 47) is never received on the server. 2. I am even able to connect to the programmatic standpoint. If you comment out lines 39 thru 47, you'll get a 404 on line 50. The attachment is an Eclipse project. To build, go to /build and run ant with no target. It will build, package as WAR and deploy to directory defined by the tomcat.home property in the build.properties file. Note that the app will be deployed as ROOT.war, and run on the / context path. Thanks in advance! -Igor. On Mon, Aug 5, 2013 at 10:52 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, On Tue, Aug 6, 2013 at 1:03 AM, Igor Urisman igor.uris...@gmail.com wrote: Dear all, I am running into snags with the new JEE7 compliant implementation of Websockets in 8.0.0-RC1. What's the right way to pass on the test cases? -Igor. Can you give more details what problems you have ?
8.0.0 Problems With javax.websocket.*
Dear all, I am running into snags with the new JEE7 compliant implementation of Websockets in 8.0.0-RC1. What's the right way to pass on the test cases? -Igor.
Tomcat Websocket Implementation
Dear all, I'm looking into a solution that will make extensive use of websockets. Details are unimportant, but here's the question that I'd like to have some insight into. The current implementation (official examplehttp://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/examples/WEB-INF/classes/websocket/chat/ChatWebSocketServlet.java?revision=1354477view=markup) seems independent of the JSR 356http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm. Is work underway to implement the javax.websocket.* objects, or is what's in org.apache.catalina.websocket it for the enforceable future? Thanks in advance, --Igor. www.sanguinecomputing.com
Re: Tomcat Websocket Implementation
Super helpful -- thanks, Nick. I'll switch to T8 right away. It's alpha status is not a problem in my case. -Igor. On Fri, Aug 2, 2013 at 10:45 AM, Nick Williams nicho...@nicholaswilliams.net wrote: On Aug 2, 2013, at 12:42 PM, Nick Williams wrote: On Aug 2, 2013, at 12:05 PM, Igor Urisman wrote: Dear all, I'm looking into a solution that will make extensive use of websockets. Details are unimportant, but here's the question that I'd like to have some insight into. The current implementation (official example http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/examples/WEB-INF/classes/websocket/chat/ChatWebSocketServlet.java?revision=1354477view=markup ) seems independent of the JSR 356http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm. Is work underway to implement the javax.websocket.* objects, or is what's in org.apache.catalina.websocket it for the enforceable future? Tomcat 8 has a completed (though not yet fully tested and vetted) implementation of JSR-356. We're voting right now on the developer's mailing list whether to release Tomcat 8.0.0-RC1 alpha. Though Tomcat 8 is the only Tomcat that will support the Servlet, JSP, and EL specifications included in Java EE 7 (they will not be back-ported to Tomcat 7), a decision was made a while ago to deprecate the existing Tomcat 7 WebSocket implementation and back-port JSR-356 to Tomcat 7. This is the only Java EE 7 component that will be back-ported to Tomcat 7, AFAIK. I don't personally know this will happen (I'm not one of the developers), but since the JSR-356 implementation in Tomcat 8 is complete now, it shouldn't be too long. **I don't personally know WHEN this will happen… If you want to play with the JSR-356 implementation for now, feel free to download and use Tomcat 8 RC1 when it releases in (hopefully) the next few days. We encourage it, because the more people who download it and try it out, the better our chances of chasing down and fixing bugs now instead of after a general release. You could also download the POTENTIAL release candidate that is being voted on right now ( https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC1/bin/), but I can't guarantee that this is the actual release candidate that will come out. Nick
Resource management in new Tomcat JDBC connection pool.
Hello, The new Tomcat 7 JDBC poolhttp://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.htmlis quite new and not much has been written on it yet. Has anyone looked it how well it manages underlying resources, both in java domain and in the database? More specifically, what happens when I call Connection.close() without explicitly first closing statements and result sets that were created via this connection? An un-pooled raw JDBC connection will do the right thing and close underlying resource when closed. But in a pool setup, connection close() simply returns it to the pool. In an ideal world, a pooled connection proxy will keep track of the underlying resources and release/close them when closed. But that's known not to have been the case in the past and I didn't find any guarantees of that in the docs for the new pool. I've been running some tests and I am coming up with surprises. I don't want yet to post code to this list. Just a general inquiry for now. Thanks in advance, -Igor.
Re: Resource management in new Tomcat JDBC connection pool.
Thanks, Dan et al. StatementFinalizer is exactly what I was looking for. A quick look at the source codehttp://javasourcecode.org/html/open-source/tomcat/tomcat-7.0.29/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java.html reveals exactly what I needed to know: statements are stashed away and individually closed on Connection.close(). -Igor. On Wed, Apr 10, 2013 at 1:26 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: Hi, Have a look at http://markmail.org/thread/**iqgvj34347z77tnchttp://markmail.org/thread/iqgvj34347z77tncfor a bug in the current Tomcat version and its workaround. This seems to affect MySQL primarily. Regards, Bertrand On 10/04/2013 4:05 PM, Igor Urisman wrote: Hello, The new Tomcat 7 JDBC poolhttp://people.apache.org/**~fhanik/jdbc-pool/jdbc-pool.**htmlhttp://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html is quite new and not much has been written on it yet. Has anyone looked it how well it manages underlying resources, both in java domain and in the database? More specifically, what happens when I call Connection.close() without explicitly first closing statements and result sets that were created via this connection? An un-pooled raw JDBC connection will do the right thing and close underlying resource when closed. But in a pool setup, connection close() simply returns it to the pool. In an ideal world, a pooled connection proxy will keep track of the underlying resources and release/close them when closed. But that's known not to have been the case in the past and I didn't find any guarantees of that in the docs for the new pool. I've been running some tests and I am coming up with surprises. I don't want yet to post code to this list. Just a general inquiry for now. Thanks in advance, -Igor. --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
