Closed glassfishrobot closed 17 years ago
@glassfishrobot Commented jfarcand said: Should have read:
but introduce a significant performance REGRESSION
@glassfishrobot Commented gfbugbridge said:
@glassfishrobot Commented jfarcand said: This is a not a bug. When an SSL connection is keep alived, Grizzly flush the bytes and might not close the connection immediately when honoring the keep-alive header. The client shouldn't expect the connection to be automatically closed after a flush.
The recent EE QL failures are produced because the CLI client is expecting the connection to get closed by Grizzly automatically, which is not exactly correct. The client should close its connection when no bytes are read (since the client socket is blocking).
@glassfishrobot Commented Was assigned to jfarcand
@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-1603
@glassfishrobot Commented Reported by jfarcand
@glassfishrobot Commented Marked as incomplete on Wednesday, November 29th 2006, 6:04:31 am
Since 3 months GlassFish is running its secure port using SSL & non blocking. For an unknown reason the EE QL started failing recently and the root cause is because SSL + NIO non blocking. Rolling back all Grizzly SSL changes until August aren't fixing the EE QL failure (which can be reproduced by invoking asadmin start-instance). Most probably the exception was swallowed by another problem outside Grizzly until recently. Turning off SSL + NIo fixe the problem:
<http-listener ....>
...
but introduce a significant performance improvement.
Environment
Operating System: All Platform: All
Affected Versions
[9.1pe]