users@glassfish.java.net

Re: EJB timer service can not automatically migration

From: <shockwave_115_at_hotmail.com>
Date: Mon, 23 Feb 2009 13:49:34 +0800

Hi
    It's very strange, when I restart the DAS, I can only found the
memberID: server and instance1 in the log of instance1

[#|2009-02-23T13:42:10.301+0800|INFO|sun-appserver9.1|ShoalLogger|_ThreadID=13;_ThreadName=ViewWindowThread;|GMS
View Change Received: Members in view (before change analysis) are :
1: MemberId: server, MemberType: SPECTATOR, Address:
urn:jxta:uuid-3E8A9E516D3C4E83910A81CAE3458DE02DE658F932AB436995B78E0CB3E080DA03
2: MemberId: instance1, MemberType: CORE, Address:
urn:jxta:uuid-3E8A9E516D3C4E83910A81CAE3458DE07987FC1134E54090AB24B0C9E01AD7DF03|#]

The membership information of instance2 is missing.
Instance1 and server(DAS) are on the same node, instance2 is on the other
node, is it the root cause of the failure of automatically migration?

What may be the root cause of this problem?


BRs
//Jason

--------------------------------------------------
From: <shockwave_115_at_hotmail.com>
Sent: Sunday, February 22, 2009 1:05 PM
To: <users_at_glassfish.dev.java.net>; <Marina.Vatkina_at_Sun.COM>
Subject: Re: EJB timer service can not automatically migration

> How to enable these two features? I didn't see any specification for this
> part.
>
> When I do prototype on one machine with two instances, I just to use the
> default configuration, and the timer service can migrate from the failure
> node to the other automatically.
>
> BRs
> //Jason
>
> --------------------------------------------------
> From: "Marina Vatkina" <Marina.Vatkina_at_Sun.COM>
> Sent: Saturday, February 21, 2009 9:10 AM
> To: <users_at_glassfish.dev.java.net>
> Subject: Re: EJB timer service can not automatically migration
>
>> Jason,
>>
>> Did you enable timer migration? If yes, you might also need to enable
>> delegated transaction recovery in order to automatically migrate timers.
>>
>> thanks,
>> -marina
>>
>> shockwave_115_at_hotmail.com wrote:
>>> Hi
>>>
>>> When I look into the source code, I found the timer migration is invoked
>>> by
>>> AdminEventMulticaster.multicastEvent(AdminEvent event), so does it means
>>> the
>>> node failure event is monitored by DAS instead of other instance? If so
>>> how
>>> can I achieve the HA if DAS crashed?
>>>
>>> And the automatically migration problem is still there, I don't know how
>>> to
>>> do further investigation, I stop one instance on node one, I can see
>>> nothing
>>> showed in the logs of instance two on the node two.
>>>
>>> For my understanding, at least instance two should have the heartbeat
>>> with
>>> instance one, so when instance one crashed, instance two can know it. If
>>> so,
>>> why use multicast?
>>>
>>> BRs
>>> Jason
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>