Konstantin,
> Right, I also think the calls to getBasicRemote().sendText(...) should
> be synchronized as multiple threads can concurrently access this method for
> a particular client (that however could mean that if one client stops
> receiving from its WebSocket connection, no other client ca
On 19/11/2013 17:12, Johan Compagner wrote:
>>
>>> I expect that i can send now 32K at
>>> once of text (or binary) withing that "continuation frame"
>>
>> The buffer sizes control the input buffer - i.e. they control the
>> maximum size of a message that can be received if an application doesn't
>
Hi Johan,
> -Original Message-
> From: Johan Compagner [mailto:jcompag...@servoy.com]
> Sent: Tuesday, November 19, 2013 6:13 PM
> To: Tomcat Users List
> Subject: Re: setting the text or binary buffer size for websockets
>
> >
> > > I expect that i can s
>
> > I expect that i can send now 32K at
> > once of text (or binary) withing that "continuation frame"
>
> The buffer sizes control the input buffer - i.e. they control the
> maximum size of a message that can be received if an application doesn't
> support partial messages.
>
> The output buffer
On 19/11/2013 14:15, Johan Compagner wrote:
> If i run that (http://localhost:8080/examples/websocket/chat.xhtml)
>
> Type in a string that will go over the 8K boundary
> Then in chrome it will still display a frame of 8K and then "continuation
> frame (Opcode 0)" which is the rest.
>
> am i exp
Hi
I have just tested it more, now just with the examples tomcat ships (the
chat example)
What i first did is add in web.xml these lines:
org.apache.tomcat.websocket.textBufferSize
32768
org.apache.tomcat.websocket.binaryBufferSize
32768
(right after metadata-complete="true
On 19 November 2013 03:55, Igor Urisman wrote:
> 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";
>
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://ja
>
>
> >> 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.ap
On 17/11/2013 13:09, Johan Compagner wrote:
> On 17 November 2013 12:55, Mark Thomas wrote:
>
>> On 16/11/2013 14:12, Johan Compagner wrote:
>>
>>> We have problems (with chrome) with all kinds of errors when sending
>> these
>>> frames (invalid opcode, utf char encoding problem, reserved words 1
On 17 November 2013 12:55, Mark Thomas wrote:
> On 16/11/2013 14:12, Johan Compagner wrote:
>
> > 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
On 16/11/2013 14:12, Johan Compagner wrote:
> 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
Exact
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
>
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 m
14 matches
Mail list logo
