Salut
Harsha Godugu wrote:
> Jan Luehe wrote:
>
>> During its execution, QL creates a new http-listener on port 1234, and
>> then removes it.
>>
>> I see these dynamic reconfig events, in this order:
>>
>> HttpService config changed ADD interface
>> com.sun.enterprise.config.serverbeans.HttpListener
>>
>> HttpService config changed CHANGE interface
>> com.sun.enterprise.config.serverbeans.HttpService
>>
>> HttpService config changed REMOVE interface
>> com.sun.enterprise.config.serverbeans.HttpListener
>> org.glassfish.config.support.GlassFishConfigBean_at_55a58f
>>
>> I can explain the ADD and REMOVE events (which are related to the
>> creation and removal of the new http-listener ("ls123456") on port 1234,
>> respectively), but I'm not sure about the CHANGE event affecting
>> http-service, which causes all http-listeners (except for
>> admin-listener), including the one on 8080, to be restarted, which is
>> causing the subsequent "connection refused" error because the test
>> does not wait long enough for the listener (in this case
>> http-listener-1) to have completed its restart before accessing it.
>>
>> Is the CHANGE event for http-service related to the fact that the new
>> http-listener (on port 1234) declares the server with id "server" as its
>> default-virtual-server, meaning that the "http-listeners" attribute of
>> this
>> virtual server is updated to include the new http-listener ("ls123456"),
>> in addition to "http-listener-1" (the listener on port 8080)?
>>
>> Question to the admin team:
>>
>> Rather than emitting a CHANGE event for http-service, could this have
>> been emitted as a CHANGE event for the virtual-server "server", which
>> would
>> be more limited in scope and would avoid a restart of all
>> http-listeners, and
>> ultimately the issue we are seeing?
>
> Another question:
>
> Since this is related to dynamic reconfiguration, why does not server do
> this seamlessly... by queuing the incoming requests, or wait until all
> the requests are processed before going for restart ?
You cannot queue all requests when you shutdown the TCP port and its
associated tcp connection (this is what's happening :-)) When we execute
a dynamic reconfig, we must bring down the port and re-open it. Once we
have grizzly-config support in domain.xml the situation should be
better, e.g changing http-service/http-listener should not affect
Grizzly. More important, we will probably be in a better position to
reduce the situation where the TCP port is closed and re-opened (binding
the socket to the port).
A+
-- Jeanfrancois
>
> thanks..
>
>>
>> Thanks,
>>
>> Jan
>>
>> On 09/ 9/08 09:42 AM, Jeanfrancois Arcand wrote:
>>
>>> Hi,
>>>
>>> I've just re-assign issue:
>>>
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6001
>>>
>>> Can someone from SQE take a look at the issue description. The fix is
>>> there :-)
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>