Re: HttpSessionBindingListener details

[Igor Urisman]

Right, makes sense. Thank you.

On Thu, Feb 5, 2015 at 10:21 AM, Konstantin Kolinko 
wrote:

> 2015-02-05 21:07 GMT+03:00 Igor Urisman :
> > 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

[Igor Urisman]

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.

[Igor Urisman]

Johan,


On Thu, Jan 2, 2014 at 1:25 AM, Johan Compagner wrote:

> 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  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.

[Igor Urisman]

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.

[Igor Urisman]

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.

[Igor Urisman]

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

[Igor Urisman]

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:



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">

FERMI Framework Test Application


   org.apache.tomcat.websocket.textBufferSize
   10240




-Igor.


On Sun, Nov 17, 2013 at 7:15 AM, Johan Compagner wrote:

> >
> >
> > >> 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

[Igor Urisman]

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 wrote:

> sorry, mail did go to soon...
>
> I do this in the web.xml (directly in the web-app tag)
>
> 
> org.apache.tomcat.websocket.textBufferSize
> 32768
> 
> 
> org.apache.tomcat.websocket.binaryBufferSize
> 32768
> 
>
> 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  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

[Igor Urisman]

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" 
> 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

[Igor Urisman]

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  wrote:

> On Tue, Sep 24, 2013 at 8:15 AM, Igor Urisman  >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  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

[Igor Urisman]

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  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

[Igor Urisman]

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  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.html>but
> > that's not in Java EE 7.
>
> Another incorrect statement. MessageHandler.Whole 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.Partial {
> >
> > 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.Whole.
> 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

[Igor Urisman]

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.html>but
that's not in Java EE 7.

So, just as a specific example, my implementation looks like the following:

public class FermiMessageHandler implements MessageHandler.Partial {

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  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

WebSocket message size limits

[Igor Urisman]

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.

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

[Igor Urisman]

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
>
>

8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

[Igor Urisman]

Dear all,

It appears that if I obtain the ServletContext object via Spring's
WebApplicationInitializer
mechanism,
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 Exception

[Igor Urisman]

Right on.  Thank you both, Mark and Niki.
-Igor.


On Sun, Sep 1, 2013 at 3:00 AM, Mark Thomas  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 
> wrote:
> >
> >> On Sat, Aug 31, 2013 at 12:33 AM, Igor Urisman  >>> 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
>
>

Re: 8.0.0-RC1: WebSocket Exception

[Igor Urisman]

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  wrote:

> On Sat, Aug 31, 2013 at 12:33 AM, Igor Urisman  >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.
> >
>

8.0.0-RC1: WebSocket Exception

[Igor Urisman]

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.

A Couple of 8.0.0 WebSocket Questions

[Igor Urisman]

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.*

[Igor Urisman]

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 wrote:

> Hi Igor,
>
> Send this message to Tomcat's users mailing list.
>
>
> On Tue, Aug 6, 2013 at 9:05 PM, Igor Urisman wrote:
>
>> 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 wrote:
>>
>>> Hi,
>>>
>>>
>>> On Tue, Aug 6, 2013 at 1:03 AM, Igor Urisman 
>>> 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.*

[Igor Urisman]

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.

Re: Tomcat Websocket Implementation

[Igor Urisman]

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=1354477&view=markup
> >)
> >> seems independent of the JSR
> >> 356<http://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
>

Tomcat Websocket Implementation

[Igor Urisman]

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)
seems independent of the JSR
356.
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: Resource management in new Tomcat JDBC connection pool.

[Igor Urisman]

Thanks, Dan et al.
StatementFinalizer is exactly what I was looking for.  A quick look at
the source
code<http://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/**iqgvj34347z77tnc<http://markmail.org/thread/iqgvj34347z77tnc>for
>  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
>> pool<http://people.apache.org/**~fhanik/jdbc-pool/jdbc-pool.**html<http://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.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Resource management in new Tomcat JDBC connection pool.

[Igor Urisman]

Hello,

The new Tomcat 7 JDBC
poolis
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.