JF,
I am not sure I understand your recommendation. You recommend
that we should see if 1234 is alive before sending requests.
But... we are not sending any requests to 1234. I added this test
to ensure that http listener can be created in config, gets listed in
the list-http-listeners command and gets deleted when delete-http-listener
returns success.
None of the above should affect any listener other than "ls123456" that
listens momentarily on port 1234. So, I think I agree with Jan's assessment
that somehow an erroneous event makes entire http-service reconfigure
itself resulting in undesirable side effects.
Jan,
A quick check on http-service reveals that there are no attributes on
it. So, till Jerome/I get time to investigate this, can you just ignore
the CHANGE event on element http-service to resolve this immediate problem?
Regards,
Kedar
Jeanfrancois Arcand wrote:
> Salut,
>
> Jan Luehe wrote:
>> 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.
>
> Right, but I was more concerned about the creation of listener 1234. If
> we try to connect on that port, there is chances the listener has not
> yet started, hence it will produce the ConnectException. I fully agree
> about port 8080...but right now there is no guarantee that 1234 will be
> started when we try to connect to it. That's why I recommend the QL be
> modified to makes sure the port is alive before sending requests. Some
> kind of ping mechanism.
>
> A+
>
> -- Jeanfrancois
>
>
>>
>>
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>