On 2/9/11 6:08 PM, Thomas Karolski wrote:
> Hello Joe,
>
> you were right - using getFromCacheForPattern works. Unfortunately I
> could not get the additional logging (FINER) to work. I've tried to
> add the following to the logging.properties file (I've copied over the
> default logging.properties from my lib directory and modified that):
>
> ShoalLogger = FINER
My mistake.
It is ShoalLogger.level=FINER.
>
> but that did not seem to change the logging level. Note also, that
> setting the DSC value *after* the group is up, does not work either
> (this is what I have been doing all along).
> Do I possibly have to state a namespace before the ShoalLogger?
Since I am uncertain how you are setting the DSC, it is easiest to point
you at a working example usage of setting a DistributedStateCache value.
Look at method ApplicationServer.addMemberDetails() in Java test file
<workspace>/gms/tests/com/sun/enterprise/ee/cms/tests/ApplicationServer.java.
This method sets the DSC values.
For extracting the DSC values, see the method extractMemberDetails() in
GMSClientService.java.
It only demonstrates getting the member details for the instance
relating to the notification.
Here is the getter method from Shoal GMS code that is being called to
get info from the DSC.
/**
* returns the details of the member who caused this Signal to be
generated
* returns a Map containing key-value pairs constituting data
pertaining to
* the member's details
* @return Map - <Serializable, Serializable>
*/
public Map<Serializable, Serializable> getMemberDetails ( ) {
return ctx.getDistributedStateCache()
.getFromCacheForPattern("MEMBER_DETAILS", failedMember );
}
To run the above test sample yourself, see description on how
to build and run shoal gms developer tests at following link.
http://shoal.java.net/HowToBuildSource.html
To set logging to FINER for these tests, edit variable in
runsimulatecluster.sh
from
SHOALGMS_LOG_LEVEL=CONFIG
to
SHOALGMS_LOG_LEVEL=FINER
-Joe
-Joe
>
> Kind regards,
> Thomas
>
> Thomas,
>
> In the log for A, I found the following events.
>
>> 09.02.2011 09:42:14
>> com.sun.enterprise.ee.cms.impl.base.ViewWindowImpl newViewObserved
>> INFO: GMS1016: Analyzing new membership snapshot received as part
>> of event: ADD_EVENT for member: server9081 of group: default
>> 09.02.2011 09:42:17
>> com.sun.enterprise.ee.cms.impl.base.GroupCommunicationProviderImpl sendMessage
>> WARNUNG:
>> GroupCommunicationProvider.sendMessage(target=server9081): unable
>> to send message: missing mapping from member identifier to
>> network peerid
>> 09.02.2011 09:42:17
>> com.sun.enterprise.ee.cms.impl.base.ViewWindowImpl
>> addJoinNotificationSignal
> What this indicates to me is that the send message that failed is
> quite likely an attempt to synchronize the distributed state cache
> over TCP.
> The DistributedStateCache synchronize is the first communication
> between instances using TCP (other communications are UDP multicast).
> A workaround is to delay setting DistributedStateCache values
> until the group is up.
>
> We can confirm the issue by enabling "ShoalLogger" to "FINER".
> Add the following line to the java command starting the shoal gms
> client,
> -Djava.util.logging.config.file=./logging.properties and add the line
> "ShoalLogger FINER" to logging.properties file to enable
> ShoalLogger logging at FINER level.
> That log level will print out lots of info including distributed
> state cache info.
>
> Another workaround is to "get" values using
> DistributedStateCache.getFromCacheForPattern(final String
> componentName, final String memberToken).
> This method not only looks in local cache but will double check if
> the value has been set in the cluster by attempting to "pull" the
> value in.
> The "pull" makes up for the failed "push" in the log file above.
>
> -Joe
>
> On 2/9/11 3:48 AM, Thomas Karolski wrote:
>
> AANLkTikunN2WPCERWrh+xWfQyh6qzx20=QnsgQLDghpy_at_mail.gmail.com
> <mailto:QnsgQLDghpy_at_mail.gmail.com>" type="cite">
> Hi Shreedhar,
>
> thanks for the response, here is the output of both A and B
> attached to this mail.
>
> Kind regards,
> Thomas
>
> Hi Thomas
> Are the two instances being reported as seeing each other
> in the view in your logs?
>
> Could you share your log output?
>
> Thanks
> Shreedhar
>