What's somewhat different in your case is the problem is repeating. But it doesn't happen 100% of the time -- MERGE2 schedules a fixed delay task to send a discovery message, and your log messages aren't happening with fixed spacing. It is happening often though.

JGroups should probably treat this InterruptedIOException differently from other IOExceptions, perhaps log it at WARN without a stack trace. I'll file a JIRA to do that, but first I want to explore more why this happens.

1) You say 4.2.3 is OK. But nothing in 4.2.3 by default uses MPING. MPING comes into AS 5.x via one of the JGroups channels used by the messaging server. Have you changed the 4.2.3 configuration so it uses a JGroups channel with MPING? Clarifying this prevent a wrong path of looking for differences in JGroups between the version used in 4.2.3 and the one in 5.1.0.

2) Have you adjusted the JGroups protocol stack configurations? If so what's the value of the MPING protocol's "timeout" attribute on any configuration that's using MPING.

3) Is your server under load, particularly load that generates lots clustering traffic? I'm wondering if the processing of scheduled tasks is being delayed.

4) If yes to question 3) was the HP-UX machine that didn't have this problem also under equivalent load?

1) You say 4.2.3 is OK. But nothing in 4.2.3 by default uses MPING. MPING comes into AS 5.x via one of the JGroups channels used by the messaging server. Have you changed the 4.2.3 configuration so it uses a JGroups channel with MPING? Clarifying this prevent a wrong path of looking for differences in JGroups between the version used in 4.2.3 and the one in 5.1.0.

I don't see any probe.sh output attached. Could you attach it to the JIRA?

Are you using clustered JBoss Messaging? If not we can explore workarounds to eliminate the usage of MPING. (Even if you're using clustered JBM we can do that; the workaround is just simpler if you're not.)

Also, please confirm that you're not seeing any unusual (i.e. WARN or ERROR) logging from other than MPING. The AS opens other channels that periodically send multicast messages; if this is the only place that is logging, that helps shift suspicion away from a general problem with sending multicast and more toward how MPING specifically does it.

I don't see any probe.sh output attached. Could you attach it to the JIRA?

Ok, done.

Are you using clustered JBoss Messaging? If not we can explore workarounds to eliminate the usage of MPING. (Even if you're using clustered JBM we can do that; the workaround is just simpler if you're not.)

No, only SLSB.

Also, please confirm that you're not seeing any unusual (i.e. WARN or ERROR) logging from other than MPING. The AS opens other channels that periodically send multicast messages; if this is the only place that is logging, that helps shift suspicion away from a general problem with sending multicast and more toward how MPING specifically does it.

Thanks, nothing in that server.log is relevant (which is what I expected). And that's helpful information as it tells me the 3 other JGroups channels that the AS "all" config starts by default aren't reporting problems. Those use a slightly different approach to send multicast discovery messages (PING protocol + UDP protocol instead of just MPING protocol).

As to the workaround, since you aren't using clustered JBoss Messaging, you can make this problem go away by switching JBM to non-clustered operation.To switch JBoss Messaging to non-clustered operation, in server/all/deploy/messaging edit the <somename>-persistence-service.xml file and in the jboss.messaging:service=PostOffice mbean configuration:

I have faced similar issue on JBoss 5.1.0 cluster on Solaris Zones. After viewing the discussion and going through https://issues.jboss.org/browse/JGRP-1161 , I have downloaded the latest jgroups.jar (2.6.15) and applied on both Jboss nodes. Restarted the servers, but still the problem is not yet resolved for me.

On the same Solaris Zone machines, I have setup JBoss4.2.3 cluster and didnt face any error as mentioned in the post.