dev@glassfish.java.net

Re: (QL failure) Issue 6001 has been re-assigned to SQE-Test

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Tue, 09 Sep 2008 14:23:07 -0700

Kedar,

On 09/ 9/08 01:58 PM, Kedar Mhaswade wrote:
> Jan,
>
> Good sleuthing on your part!
>
> I will take this offline with you (and Jerome), but I think CHANGE
> event not at all required in this case on any element. Delivering
> a CHANGE event on virtual-server is not optimal because that means
> event framework knows about http-listeners attribute on it which
> is certainly not desired. CHANGE event on http-service looks extraneous
> in this case and looks like a side-effect of the previous ADD. Also
> remember that CHANGE is not sent after DELETE!

Yes, this inconsistency really suggests that the CHANGE event should not
have been delivered at all in this case.

> A CHANGE on a given
> element invariably should imply change in the value of its attributes
> and should not have to do anything with its child elements.
>
> So, this looks like an oversight.
>

OK! So, can I assign 6001 to you? :)

I'm afraid that adding a sleep to the test will only mask this issue
going forward.

Thanks,

Jan

> -Kedar
>
>
> 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?
>>
>> 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
>