Hi Jeanfrancois,
On 09/ 9/08 02:25 PM, Jeanfrancois Arcand wrote:
> Salut,
>
> Jan Luehe wrote:
>> 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.
>
> Hum :-) But the problem will arise anyway with the newly created
> http-listener. Since the create-listener operation is asynchronous,
> you cannot predict when the port will be ready for listening unless
> you sleep or ping it. I agree fixing the current issue will makes QL
> pass, but I suspect it may still fail on super fast machine with
> multiple core.
>
> Wild guest :)
OK. :)
But the test fails when it tries to access the listener on 8080 (not the
one on 1234),
which should not have been affected by the listener creation on 1234.
The listener on 8080 is created when the domain is started, so it should
be immune
to the creation of any other http listeners, and should always be able
to serve
requests.
The only reason the listener on 8080 is brought down right now (and not
brought
up quickly enough to serve the next request) is because of the
extraneous CHANGE
event that Kedar is looking into.
Jan
>
> A+
>
> --Jeanfrancois
>
>
>
>>
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>