Will changing CHANGE event to be an ADD event for an add operation stop
delivering changed() callbacks to the ConfigListener impls?
If yes, it'll break what Jerome convinced me to be the right thing to do for the
tx service reconfiguration :(. Tx Service is there always, but a property can be
added to it.
thanks,
-marina
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.
>
> 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
>