Siva/Ramesh,
I agree with Tim that a unit test must be put in place so that it
doesn't happen again.
Also, there should be a unit test in place for the long startup delay
problem that occurred recently.
I recall that there have been past network-related issues. All such
things deserve unit tests to avoid regressions, and MQ integrations
should pass both requirements before being submitted.
Lloyd
On Mar 13, 2007, at 10:03 AM, Sivakumar Thyagarajan wrote:
> Hi Ken and Tim
>
> I agree that this is a regression (in PE [1]), for systems that
> have been configured such that their hostnames are mapped to the
> loop-back address [127.0.0.1]. We have seen this occur on Linux
> systems [Ubuntu etc] usually, where /etc/hosts is configured as
> described above as the default.
>
> We have already asked the OpenMQ team about this and they already
> have a fix in their nightlies and should be available in the next
> integration. We would get a drop during the end of this week and
> hopefully next week's promotion would have a fix for this. We will
> let this list know as soon as this is fixed.
>
> Thanks
> --Siva
> [1] I said PE, because EE cluster instances have always had this as
> a limitation because MQ does not support broker clusters on
> machines with loopback addresses.
>
> Tim Quinn wrote:
>> Ken Paulsen wrote:
>>>
>>> This is significant regression. When will the next MQ
>>> integration be? What do you suggest for people who don't have a
>>> static IP to set it to? Do they have to find their dynamic IP
>>> and set it in the /etc/hosts file every time it changes?
>>>
>> It's a significant regression in what I think would be a common
>> use case - folks who happen to work on systems with dynamic IP
>> addresses.
>> Whenever we find a bug in the project we should be adding a unit
>> test that shows the bug before the code is fixed and verifies that
>> the fix solves the problem, thereby allowing us to detect any
>> future regression promptly and automatically. We should find
>> similar ways to build tests for this kind of scenario into our
>> automated build-and-test environments so this type of problem
>> surfaces before a promotion so at least we know what we're
>> promoting. In this case, probably the right place for such a test
>> is the MQ test suite since that's where the problem seems to have
>> originated.
>> - Tim
>>> Thanks!
>>>
>>> Ken
>>>
>>> Anissa Lam wrote:
>>>> Hi Ramesh,
>>>> That fixes the problem. Thanks for the workaround.
>>>>
>>>> Anissa.
>>>>
>>>> Ramesh Parthasarathy wrote:
>>>>> Hi Anissa,
>>>>> I think the hostname "falk" maps to a loopback address 127.0.0.1
>>>>> (/etc/hosts). Could you change this to a static ip and try.
>>>>>
>>>>> Ideally, the DAS broker (is EMBEDDED and standalone) should
>>>>> startup even
>>>>> if the ip address of the host is a loopback address. But, there
>>>>> is a
>>>>> regression in the recent MQ drop which is causing broker
>>>>> startup to fail
>>>>> if address is loopback. This will be fixed in the next MQ
>>>>> integration.
>>>>>
>>>>> Please modify your host-ip mapping in /etc/hosts to workaround
>>>>> this issue.
>>>>>
>>>>> Thanks
>>>>> -Ramesh
>>>
>> (remainder of thread clipped out)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>