glassfishrobot

@glassfishrobot Commented soylomass said: I wish I could. It happens randomly. I've changed the async sends for basic instances to see if it stops happening. I'll report.

@glassfishrobot Commented soylomass said: Basic of course went even worse, as it isn't efficient to handle a lot of writes. Pavel, do you have any idea of what could be...

@glassfishrobot Commented @pavelbucek said: You could test with different settings related to selector and worker thread pools, see [https://tyrus.java.net/apidocs/1.13/org/glassfish/tyrus/container/grizzly/server/GrizzlyServerContainer.html](https://tyrus.java.net/apidocs/1.13/org/glassfish/tyrus/container/grizzly/server/GrizzlyServerContainer.html) But I'm not sure whether that will help. The problem seems...

@glassfishrobot Commented soylomass said: Is there any equation to get the recommended number of selector/worker threads? The software is a MMO game sending and receiving from every client more than...

@glassfishrobot Commented @PetrJanouch said: Hi, my humble opinion is that this has nothing to do with threads. Grizzly has a write queue whose content it feeds to a socket when...

@glassfishrobot Commented soylomass said: What puzzles me is why the exception, once it happens, repeats itself hundreds of times in a second, if I don't make that many writes to...

@glassfishrobot Commented @PetrJanouch said: That is strange. The exception is logged once per closed connection and it will be also returned by the future/javax.websocket.SendResult of each uncompleted asynchronously written message....

@glassfishrobot Commented soylomass said: I would like to check that. I should use Future.get() to know that, right? In that case, the operation will be similar in performance to sending...

@glassfishrobot Commented soylomass said: EDIT: I've checked the logs once more, and the exceptions start to happen always after a user disconnects (as it's catched by the onClose callback): Close...

@glassfishrobot Commented @PetrJanouch said: I have just figured out what happened. The message can be really logged enormous amount of times per one closed connection. I will fix it tomorrow...