You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
unable to receive message size more than 8192 char #525
first of all sorry for the delayed response. I was on holiday for a few days and normally don't read any emails.
I think this issue is related to #423.
Does it always not work for messages longer then 8192 characters? Does it just not work for TextFrames or also for BinaryFrames?
Greetings
marci4
EDIT:
Tested it with a longer message and it works. What are you doing different? http://imgur.com/a/fXJsp
Hi Marcel,
It is not working for textframes.
I have added the below code in line 370 in WebSocketImpl.java.
wsl.onWebsocketMessage( this, Charsetfunctions.stringUtf8(
current_continuous_frame.getPayloadData() ) );
It works. But is it the correct way?
I'm using 1.3.3 version.
Thanks,
Ayyappan N
On Wed, Jul 26, 2017 at 8:07 PM, Marcel Prestel ***@***.***> wrote:
Hello @ayyappan6031 <https://github.com/ayyappan6031>,
first of all sorry for the delayed response. I was on holiday for a few
days and normally don't read any emails.
I think this issue is related to #423
<#423>.
Does it always not work for messages longer then 8192 characters? Does it
just not work for TextFrames or also for BinaryFrames?
Greetings
marci4
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#525 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADDKa54ZrI5hJGP5z0mzBOhJAT_JplEIks5sR08SgaJpZM4OiYWo>
.
Hi marcel,
Thank you for quick response. I tried the latest version 1.3.4 also. I'm
not getting the messages larger than 8192 chars. I have attached the sample
message text file.
right now I cannot reproduce this issue with my development branch....
Do you use both client and server from this project or are you using different components?
I'm also having this issue. I am using text messages. I'm haven't quite learned to navigate the code yet, but I may have spotted something that helps.
Looking at WebSocketInpl.java, it looks like there is a loop in decodeFrames which accepts incoming frames from the socket buffer. When a frame is not finished, it is stored in the class member element current_continuous_frame. When a future frame is received with a "fin" value of true, its content is appended to the current_continuous_frame. But, IMMEDIATELY AFTER, the current_continuous_frame is set to null (line 419 or thereabouts). So both the data from the original frame and the incoming frame is lost.
Also, I notice that there are methods with the name onWebsocketFragment which appear to be do-nothings. Is that correct?
Hope some of this helps.
Gary
P.S. Maybe there needs to be a call to wsl.onWebSocketMessage() after the append?
P.P.S. Okay, I tried putting in the call and it seems to work. I am now receiving 15 K length text messages just fine.
Also, this is off topic a little, but I have a question. I notice that PONG messages are being passed to the onMessage method of the WebSocketClient class as text messages. I'm new to websockets, so I have to ask. Is this a correct behavior? It seems to me that a PONG is something quite distinct from a text message and that the logic I've had to add to handle it (look for a 1 character message, check to see if that character is a linefeed) is kind of a kludge.
Please tell me what server and client you are using (as well as ws or wss).
And does this always happen with every random message bigger then 15k characters?
Tell me what you are doing different to me ;)
Tried it with chrome as client as well as just java-websocket server and client and it always works for me...
The code you are mentioning is not writen by me. So I do have to read/understand it myself ;)
onWebsocketFragment is an old API, which I probably will deprecate over time (like I did with the drafts)
Regarding the PONG message, no this should not be the case and it is also not the case for me...
PONG messages are specified by the spec and have their own opcode, so you have to handle these separat to a text message for example!
Well, as I said I’m new to websockets (and web technology in general), so please excuse me if I get some terminology wrong. Also, I didn’t set up the server, so I’m not 100 percent sure what they’re doing on that side… I’ll try to provide the details as I understand them.
The place where I am running into trouble is in a websocket client application. The server is providing text message responses that are larger than 8K (1 frame?) and things fall apart when the incoming message is larger than 8K. I think the application running on the server side is an Apache message queue. The application I wrote is essentially a reverse proxy which accepts connections from the Internet and relays traffic to a protected server where the data originates (with some extra statistics gathering and other non-related processing).
From your description, it sounds to me that in the Chrome test you mention, Chrome would be the client and be performing in the same role as my proxy application.
I could take a cut at cleaning up the code in WebSocketImpl.java, but I really don’t have the set up right now to test it adequately for applications other than my own. The good news is that the problem in the decodeFrames code sticks out like a sore thumb, so that should make it a bit easier to read.
Gary
From: Marcel Prestel [mailto:notifications@github.com]
Sent: Wednesday, August 02, 2017 2:33 PM
To: TooTallNate/Java-WebSocket
Cc: gwlucas; Mention
Subject: Re: [TooTallNate/Java-WebSocket] unable to receive message size more than 8192 char (#525)
Hello @gwlucas,
I still have an issue just to reproduce it :(
Please tell me what server and client you are using (as well as ws or wss).
And does this always happen with every random message bigger then 15k characters?
Tell me what you are doing different to me ;)
Tried it with chrome as client as well as just java-websocket server and client and it always works for me...
The code you are mentioning is not writen by me. So I do have to read/understand it myself ;)
onWebsocketFragment is an old API, which I probably will deprecate over time (like I did with the drafts)
Regarding the PONG message, no this should not be the case and it is also not the case for me...
PONG messages are specified by the spec and have their own opcode, so you have to handle these separat to a text message for example!
Greetings
marci4
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
even though your help is really appreciated you would help me a lot if you could tell me exactly what you are doing so messages with a size bigger then 8k will not be send ;)
I am more used to the code and I will find a way to not break all the protocol specific requirements ;)
Apart from this, yes I will look into your mentioned code parts!
Well, let me dig a bit and ask my coworkers a few questions and see if I can think of more detail about their side of the implementation.
I can tell you that decodeFrames() is getting called multiple times and processing multiple frames. The first frame comes in with an Opcode.CONTINUOUS and a “fin” value of false. The number of bytes available is 8K. The next query comes in with fin=TRUE and the rest of the bytes. In the future, I fully expect to be dealing with larger queries. But so far it’s only been two frames.
Gary
From: Marcel Prestel [mailto:notifications@github.com]
Sent: Thursday, August 03, 2017 3:52 PM
To: TooTallNate/Java-WebSocket
Cc: gwlucas; Mention
Subject: Re: [TooTallNate/Java-WebSocket] unable to receive message size more than 8192 char (#525)
Hello @gwlucas,
even though your help is really appreciated you would help me a lot if you could tell me exactly what you are doing so messages with a size bigger then 8k will not be send ;)
I am more used to the code and I will find a way to not break all the protocol specific requirements ;)
Apart from this, yes I will look into your mentioned code parts!
Greetings
marci4
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Activity
marci4 commentedon Jul 26, 2017
Hello @ayyappan6031,
first of all sorry for the delayed response. I was on holiday for a few days and normally don't read any emails.
I think this issue is related to #423.
Does it always not work for messages longer then 8192 characters? Does it just not work for TextFrames or also for BinaryFrames?
Greetings
marci4
EDIT:
Tested it with a longer message and it works. What are you doing different?
http://imgur.com/a/fXJsp
ayyappan6031 commentedon Jul 27, 2017
marci4 commentedon Jul 27, 2017
Hello @ayyappan6031
could you possible post an example String when it is not working (like on https://gist.github.com/ ).
Could you also update to 1.3.4, since this is the latest release!
I will look into it a bit more!
Greetings
marci4
ayyappan6031 commentedon Jul 27, 2017
marci4 commentedon Jul 28, 2017
Hello @ayyappan6031,
thx a lot.
Will look into it over the weekend :)
Greetings
marci4
marci4 commentedon Jul 28, 2017
Hello @ayyappan6031,
right now I cannot reproduce this issue with my development branch....
Do you use both client and server from this project or are you using different components?
Greetings
marci4
gwlucas commentedon Aug 1, 2017
I'm also having this issue. I am using text messages. I'm haven't quite learned to navigate the code yet, but I may have spotted something that helps.
Looking at WebSocketInpl.java, it looks like there is a loop in decodeFrames which accepts incoming frames from the socket buffer. When a frame is not finished, it is stored in the class member element current_continuous_frame. When a future frame is received with a "fin" value of true, its content is appended to the current_continuous_frame. But, IMMEDIATELY AFTER, the current_continuous_frame is set to null (line 419 or thereabouts). So both the data from the original frame and the incoming frame is lost.
Also, I notice that there are methods with the name onWebsocketFragment which appear to be do-nothings. Is that correct?
Hope some of this helps.
Gary
P.S. Maybe there needs to be a call to wsl.onWebSocketMessage() after the append?
P.P.S. Okay, I tried putting in the call and it seems to work. I am now receiving 15 K length text messages just fine.
Also, this is off topic a little, but I have a question. I notice that PONG messages are being passed to the onMessage method of the WebSocketClient class as text messages. I'm new to websockets, so I have to ask. Is this a correct behavior? It seems to me that a PONG is something quite distinct from a text message and that the logic I've had to add to handle it (look for a 1 character message, check to see if that character is a linefeed) is kind of a kludge.
marci4 commentedon Aug 2, 2017
Hello @gwlucas,
I still have an issue just to reproduce it :(
Please tell me what server and client you are using (as well as ws or wss).
And does this always happen with every random message bigger then 15k characters?
Tell me what you are doing different to me ;)
Tried it with chrome as client as well as just java-websocket server and client and it always works for me...
The code you are mentioning is not writen by me. So I do have to read/understand it myself ;)
onWebsocketFragment is an old API, which I probably will deprecate over time (like I did with the drafts)
Regarding the PONG message, no this should not be the case and it is also not the case for me...
PONG messages are specified by the spec and have their own opcode, so you have to handle these separat to a text message for example!
Greetings
marci4
gwlucas commentedon Aug 3, 2017
marci4 commentedon Aug 3, 2017
Hello @gwlucas,
even though your help is really appreciated you would help me a lot if you could tell me exactly what you are doing so messages with a size bigger then 8k will not be send ;)
I am more used to the code and I will find a way to not break all the protocol specific requirements ;)
Apart from this, yes I will look into your mentioned code parts!
Greetings
marci4
gwlucas commentedon Aug 3, 2017
marci4 commentedon Aug 3, 2017
Hello @gwlucas,
this testsuite may help your coworkers! https://github.com/crossbario/autobahn-testsuite/tree/master/doc
I always test changes against this testsuite so I am sure everything is correctly implemented ;)
As you describe this, that should be working.
Greetings
marci4
marci4 commentedon Sep 15, 2017
Hello @gwlucas,
do you have any update on this issue?
Greetings
marci4
marci4 commentedon Oct 10, 2017
Could you please check if #570 is fixing this issue for you?
Greetings
marci4
marci4 commentedon Oct 12, 2017
This issue should be solved. If not feel free to open a new issue!
Greetings
marci4