Bug 197805 - jvm multicast binding on RHEL4 does not works
jvm multicast binding on RHEL4 does not works
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: java-1.4.2-bea (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Georges Saab
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-06 10:52 EDT by Laszlo Jagusztin
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHEA-2007-9027
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-24 16:29:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laszlo Jagusztin 2006-07-06 10:52:38 EDT
Description of problem:
We use Bea Weblogic 8.1SP5 with Jrockit and Sun JVM 1.4.2 on RHEL3. We upgraded 
to operating system to RHEL4, and found that the interface binding for 
multicast communication does not bind to the correct interface, it is always 
using the default interface. We tried it from a sample program, and found that 
the error is in the JVMs(on RHEL4 kernel???). 
This is a critical error for us, because our application server cluster use 
multicast for cluster communication, so on RHEL4 it does not works.
No error msg. It seems like this BUG: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4082533 but it is solved.

Version-Release number of selected component (if applicable):
OS and Kernel Version: Linux achilles1 2.6.9-34.0.1.ELsmp #1 SMP Wed May 17 
16:59:36 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:
List steps to reproduce the problem: 
socket = new MulticastSocket(i); 
if(s2 != null) 
try 
{ 
InetAddress inetaddress = InetAddress.getByName(s2); 
System.out.println("Using interface at " + inetaddress.getHostAddress()); 
socket.setInterface(inetaddress); 
System.out.println(socket.getInterface()); 
} 
catch(SocketException socketexception) 
{ 
throw socketexception; 
}

  
Actual results:
always bind to the default interface

Expected results:
bind to the selected interface

Additional info:
Comment 1 Laszlo Jagusztin 2006-07-06 10:56:05 EDT
We restored the whole Bea and JVM home from backup, so the only difference was 
is the RHEL3->RHEL4 change. Something could be wrong with the JVM-RHEL4 
multicast interface binding.
Comment 2 Laszlo Jagusztin 2006-07-23 17:00:48 EDT
We found the real problem:

The setInterface(InetAddress inf) method does not works on RHEL4. If we use it 
on RHEL3 sets the output network interface, but on RHEL4 it is always using the 
default interface for sending multicast packets even we set other interface 
before the send. The Weblogic multicast tester (and cluster..) using 
setInterface(InetAddress inf) method to set the network interface; so the 
cluster does not works on RHEL4 if you are not using the default network 
interface for WLS cluster interconnect.

We asked Bea and Sun to revoke their RHEL4 platform certification for Java and 
Weblogic until this type of problems are exists.

Reference:
http://forums.bea.com/bea/message.jspa?messageID=600039047&tstart=0
Comment 3 Laszlo Jagusztin 2006-07-25 06:37:07 EDT
We found a workaround:-Djava.net.preferIPv4Stack=true 
There should be a big problem in the IPV6 multicast stack on RHEL4..
Comment 4 RHEL Product and Program Management 2006-08-23 17:39:51 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 5 RHEL Product and Program Management 2006-08-23 17:40:06 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 7 Laszlo Jagusztin 2006-10-18 08:43:16 EDT
Helo,

Could you please update the status uf this Bug? Are there any decision?

Regards.,
LJ
Comment 8 Thomas Fitzsimmons 2006-10-23 16:27:17 EDT
(In reply to comment #7)
> Could you please update the status uf this Bug? Are there any decision?

We're working on this for RHEL-4.5.
Comment 10 Thomas Fitzsimmons 2006-10-26 14:35:57 EDT
Georges, are you aware of this bug?  Is it fixed in 1.4.2_11 R26.4.0-63?
Comment 14 Laszlo Jagusztin 2006-12-15 18:06:09 EST
Could you please update the status uf this Bug? Is is not VM specific, it is a 
kernel bug. What RHEL4-5 mean? RHEL4 update 5 or something else?

Regards.,
LJ
Comment 17 Thomas Fitzsimmons 2007-01-03 17:35:59 EST
(In reply to comment #14)
> Could you please update the status uf this Bug? Is is not VM specific, it is a 
> kernel bug.

If you have a standalone test case that reproduces the problem and demonstrates
that it is a kernel problem, then please file a separate bug report for it.

> What RHEL4-5 mean? RHEL4 update 5 or something else?

Yes, RHEL-4 Update 5.

If this is just a case of JRockit not being updated with a Sun bug fix, then the
upcoming RHEL-4.5 JRockit erratum should contain the fix, so I'm leaving this
open until then.  I recommend re-testing at that point.
Comment 19 Red Hat Bugzilla 2007-01-24 16:29:52 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-9027.html

Note You need to log in before you can comment on or make changes to this bug.