Salut,
Kedar Mhaswade wrote:
> 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.
I see. Then I agree no timeout required. I was under the impression we
were also testing 1234 to see if it worked properly.
A+
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>