The Grizzly Write Timeout Setting in the GlassFish Network Transports Configuration Does Not Change the Timeout Used by the Instance.
Last updated on NOVEMBER 05, 2016
Applies to:Oracle GlassFish Server - Version 3.0 to 3.1.2 [Release 3.0 to 3.1]
Information in this document applies to any platform.
There is no direct symptom that the write timeout in the Transport configuration screen is not being honored:
There is normally no reason to change this setting, unless the following exception is seen:
This could be at the end of a series of other exceptions, which have been left out of this article to make it clear which one is most relevant. When the write timeout is increased and the instance is restarted, the exception is still reported, regardless of the value the timeout is set to. Note that the root cause of the timeout comes from the remote client, which for some reason is not reading the response from the GlassFish listener quickly enough. This problem can potentially be seen during large, complex deployments when a GlassFish instance is synchronizing with the Domain admin server.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms