The remote endpoint was in state [TEXT_PARTIAL_WRITING]

[Former user]

Hello Peter Doornbosch,

I am using your Websocket plugin to generate some load using JMeter. I use Java 8 and Spring Boot. I created a WebSocketHandler. For the test, I use handleTextMessage which acts like an echo enpoint. I use different payload size on the same websocket connection, the maximum is 5 MB.

After I generate few messages via websocket I see:

• In JMeter: WebSocket I/O error: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException

• Console:java.lang.IllegalStateException: The remote endpoint was in state [TEXT_PARTIAL_WRITING] which is an invalid state for called method.

I observed that if I don't send back the whole message, everything is ok or for every message I create a new websocket connection. The issue is present whether I re-use the websocket connection.

Thank you, Adrian

[Grancea, Adrian-Daniel (ADV D EU RO DG)]

@Peter Doornbosch I created the post. I thought I was logged in.

[Peter Doornbosch]

Hi Adrian,

Let me check if i understand your setup correctly:

• you created a server with Java 8 and Spring boot
• the stack trace shown in the screenshot is from your server
• at the same time (? earlier? later?) your server is throwing the IllegalStateException, you see the I/O error in JMeter

Right?

I’d say, the following happens:

• your server implementation contains a bug that causes the IllegalStateException
• because of the exception, the server closes the TCP connection with the JMeter client
• the TCP close leads to an SSLException in JMeter because you’r using WSS.

Maybe, because of the exception message starting with “the remote endpoint was …. in an invalid state”, you think JMeter is in an invalid state? I don’t think so. Note the class is called “WsRemoteEndpointBasic”, that is just the (in my perception confusing) naming scheme the server uses, it’s similar to the Java API (see https://docs.oracle.com/javaee/7/api/javax/websocket/RemoteEndpoint.Basic.html): RemoteEndpoint.sendText does not mean the remote endpoint is sending .

Maybe you are accessing the RemoteEndpoint object concurrently? From the javadoc: “if two threads attempt to call a send method concurrently, or if a developer attempts to send a new message while in the middle of sending an existing one, the send method called while the connection is already busy may throw an IllegalStateException”

Hth,

Peter

[Grancea, Adrian-Daniel (ADV D EU RO DG)]

Hello Peter,

I can send you some screenshots/source code to be able to understand how I conclude to this if you want.

Also, to be able to reproduces the situation.

Best regards,

Adrian

[Peter Doornbosch]

Conclude what?

[Grancea, Adrian-Daniel (ADV D EU RO DG)]

Hello @Peter Doornbosch

I have committed an archive with a JMeter plan and a WebServer in Spring Boot.

URL: https://[e-mail]/Krict/for_peter.git → can you access it?

In Java code are two section A and B, comment one and uncomment the other one.

I had a setup JMeter → Gateway → WebSocket_Server in cloud. Using section A, in the Gateway’s logs I saw: “The remote endpoint was in state [TEXT_PARTIAL_WRITING]”. To reproduce the error on the localhost, I used section B. If use section A on localhost, you will see an timeout error. In the archive are some screenshots.

In JMeter plugin, are two plugins available for websocket. The JMeter plan uses both, in two separate Thread Group. The version for JMeter is 4.0.

Probably there can be other problem with websocket and I cannot figure it out.

Do you have any idea?

Best regards,

Adrian

[Grancea, Adrian-Daniel (ADV D EU RO DG)]

@Peter Doornbosch

After you download the archive, I want to remove it. Please let me know when you downloaded it.

[Peter Doornbosch]

Hi,

I don’t have the time to debug your server code. I invested a lot of time in this plugin that is offered to you for free. I do give help and support, but i must limit this to real issues in the plugin, because my time is limited.

It is still not clear to me what you want. I asked a few questions to which you did not respond. I explained what probably the cause is of the errors you get in your code; do did not respond to that.

If you are confident that you found an issue in the plugin, create a WireShard capture of the full communication between plugin and your code. Only that can show whether the plugin incorrectly handles the websocket messages it receives. If such a trace shows weird communication patterns, i’m happy to analyse and discuss it with you.

Regards

Peter

[Grancea, Adrian-Daniel (ADV D EU RO DG)]

Hello Peter,

Your questions:

you think JMeter is in an invalid state? --> this is my assumption
Maybe you are accessing the RemoteEndpoint object concurrently? --> single threads, very fast.

Why I open this bug report?
Because I wanted to help you, to improve the plugin. I sent you some resources to be able to reproduce the problem fast.
I didn't request you to debug my code. Websocket endpoint acts as an echo endpoint, no other business logic in the code.
I didn't put other stuff in the code.

Best regards,
Adrian

[Peter Doornbosch]

Your local endpoint (that is confusingly called “RemoteEndpoint”) is in an invalid state. The websocket protocol has no “text_partial_writing” state or something along that line. I’ve seen similar problems in Java servers using websocket endpoints before and the problem is the Java API. I don’t recall all the details exactly, but it was always that the API was called while it was in a state that it shouldn’t be called. And that’s exactly what the JavaDoc says: “or if a developer attempts to send a new message while in the middle of sending an existing one, the send method called while the connection is already busy may throw an IllegalStateException”. That it only happens when writing large(r) messages is probably because the server splits the message in multiple fragments and sending these fragments takes a little more time.

I appreciate people reporting bugs, and so i appreciate you trying to help to improve the plugin. But in this case, i’m convinced that the behaviour is not caused by a bug in the plugin. The best and most effective way to proof which component causes the trouble, is to record and analyse the communication between the two peers.

Regards,

Peter