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 19, 2023

Applies to:

Symptoms

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.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.