The Grizzly Write Timeout Setting in the GlassFish Network Transports Configuration Does Not Change the Timeout Used by the Instance.
(Doc ID 2040666.1)
Last updated on OCTOBER 29, 2020
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document