[JBoss JIRA] (JGRP-1532) Don't receive heartbeat in Nic Teaming configuration after NIC swicth
by PASCAL BROUWET (JIRA)
PASCAL BROUWET created JGRP-1532:
------------------------------------
Summary: Don't receive heartbeat in Nic Teaming configuration after NIC swicth
Key: JGRP-1532
URL: https://issues.jboss.org/browse/JGRP-1532
Project: JGroups
Issue Type: Bug
Affects Versions: 2.12.2
Environment: Windows Server Standard 2008 SP2.
two network cards Broadcom BCM5709S NetXtreme II (DualPort) with NIC-Teaming Software (
BASC3 Version 12.2.9.0. (Broadcom Advanced Control Suite 3)
Reporter: PASCAL BROUWET
Assignee: Bela Ban
we haven't problems in single cards configuration without NIC Teaming.
But with all machines with dual cards with Nic Teaming is activated, we have a problem of "didn't received heartbeat".
With WireShark analyser, we observed that when heartbeat Multicast packet stay on same card, we did not have problem but if the heartbeat Multicast packet switches to second card, we have in logs file failure detections.
For example : the first heartfailure in logs appears at 03:41:25 until 05:03:20
2012-10-23 03:41:25.234 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 11061 ms, adding it to suspect list
2012-10-23 03:41:25.234 [FINE] - FD_ALL: suspecting [ctc809091084-27510(5ae571864ef0), ctc804291084-11401(de9a6a421087)]
2012-10-23 03:41:28.245 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 14072 ms, adding it to suspect list
2012-10-23 03:41:28.245 [FINE] - FD_ALL: haven't received a heartbeat from ctc804291084-11401(de9a6a421087) for 12044 ms, adding it to suspect list
2012-10-23 03:41:28.245 [FINE] - FD_ALL: suspecting [ctc809091084-27510(5ae571864ef0), ctc804291084-11401(de9a6a421087)]
2012-10-23 03:41:31.255 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 17082 ms, adding it to suspect list
2012-10-23 03:41:31.255 [FINE] - FD_ALL: haven't received a heartbeat from ctc804291084-11401(de9a6a421087) for 15054 ms, adding it to suspect list
2012-10-23 03:41:31.255 [FINE] - FD_ALL: suspecting [ctc809091084-27510(5ae571864ef0), ctc804291084-11401(de9a6a421087)]
2012-10-23 03:41:34.266 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 20093 ms, adding it to suspect list
2012-10-23 03:41:34.266 [FINE] - FD_ALL: haven't received a heartbeat from ctc804291084-11401(de9a6a421087) for 18065 ms, adding it to suspect list
2012-10-23 03:41:34.266 [FINE] - FD_ALL: suspecting [ctc809091084-27510(5ae571864ef0), ctc804291084-11401(de9a6a421087)]
2012-10-23 03:41:37.277 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 23104 ms, adding it to suspect list
2012-10-23 03:41:37.277 [FINE] - FD_ALL: haven't received a heartbeat from ctc804291084-11401(de9a6a421087) for 21076 ms, adding it to suspect list
2012-10-23 03:41:37.277 [FINE] - FD_ALL: suspecting [ctc809091084-27510(5ae571864ef0), ctc804291084-11401(de9a6a421087)]
2012-10-23 03:41:40.288 [FINE] - FD_ALL: haven't received a heartbeat from ctc809091084-27510(5ae571864ef0) for 26115 ms, adding it to suspect list
2012-10-23 03:41:40.288 [FINE] - FD_ALL: haven't received a heartbeat from ctc804291084-11401(de9a6a421087) for 24087 ms, adding it to suspect list
...
the logs of Card 1 during the period :
----------------------------------------------------
2012-10-23 03:41:15.563 MULTICAST id=321 src=/10.120.180.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=cc74a22f-6e18-1b7a-5521-3abebdd47ab6(3ba17876e725) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:15.996 MULTICAST id=7481 src=/10.120.120.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=17da3e81-158b-4440-50c7-412aebce41e2(de9a6a421087) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 04:25:49.221 MULTICAST id=2868 src=/10.120.180.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=cc74a22f-6e18-1b7a-5521-3abebdd47ab6(3ba17876e725) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
The Cards was in standby between 03:41:15 and 04:25:49
The logs of Card 0 during the period :
-------------------------------------------------
----------------------------------------------------
2012-10-23 03:41:25.029 MULTICAST id=74b1 src=/10.120.120.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=17da3e81-158b-4440-50c7-412aebce41e2(de9a6a421087) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:25.961 MULTICAST id=5adb src=/10.120.220.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=f1e9fdac-6d36-d321-6f9d-ec0cbf771608(5ae571864ef0) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:26.874 MULTICAST id=5ae0 src=/10.120.220.64:45588 dest=/228.8.8.8:45588 (91 bytes)
Msg1 src=f1e9fdac-6d36-d321-6f9d-ec0cbf771608(5ae571864ef0) dest=ALL
flags=[OOB]
headers=[
PingHeader:[PING: type=GET_MBRS_REQ, cluster=REPL, view_id=[f1e9fdac-6d36-d321-6f9d-ec0cbf771608(5ae571864ef0)|2]]
]
----------------------------------------------------
2012-10-23 03:41:27.607 MULTICAST id=362 src=/10.120.180.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=cc74a22f-6e18-1b7a-5521-3abebdd47ab6(3ba17876e725) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:28.040 MULTICAST id=74bf src=/10.120.120.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=17da3e81-158b-4440-50c7-412aebce41e2(de9a6a421087) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:28.962 MULTICAST id=5ae8 src=/10.120.220.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=f1e9fdac-6d36-d321-6f9d-ec0cbf771608(5ae571864ef0) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
----------------------------------------------------
2012-10-23 03:41:30.617 MULTICAST id=36f src=/10.120.180.64:45588 dest=/228.8.8.8:45588 (47 bytes)
Msg1 src=cc74a22f-6e18-1b7a-5521-3abebdd47ab6(3ba17876e725) dest=ALL
flags=[OOB]
headers=[
HeartbeatHeader:heartbeat
]
etc ... heartbeats received every 3 secondes until 06:00
The two cards have been configured with the same IP Address (10.120.180.64) and also virtual NIC (10.120.180.64).
We tested with Mcast.exe on these configuration without problems.
All is working like JGroups (or JAVA) was "plugged" only the card n°1.
JGroups was been configured with this parameters.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:org:jgroups">
<UDP bind_addr="10.120.180.64" bind_interface="eth10" bind_port="7800" diagnostics_addr="224.0.75.75" discard_incompatible_packets="true" enable_bundling="true" enable_diagnostics="true" ip_ttl="10" loopback="true" max_bundle_size="64K" max_bundle_timeout="30" mcast_group_addr="228.8.8.8" mcast_port="45588" mcast_recv_buf_size="25M" mcast_send_buf_size="640K" oob_thread_pool.enabled="true" oob_thread_pool.keep_alive_time="5000" oob_thread_pool.max_threads="8" oob_thread_pool.min_threads="1" oob_thread_pool.queue_enabled="false" oob_thread_pool.queue_max_size="100" oob_thread_pool.rejection_policy="Run" singleton_name="UDP" thread_naming_pattern="pl" thread_pool.enabled="true" thread_pool.keep_alive_time="5000" thread_pool.max_threads="8" thread_pool.min_threads="2" thread_pool.queue_enabled="false" thread_pool.queue_max_size="100" thread_pool.rejection_policy="Run" tos="8" ucast_recv_buf_size="20M" ucast_send_buf_size="640K"/>
<PING num_initial_members="3" timeout="2000"/>
<MERGE2 max_interval="30000" min_interval="10000"/>
<FD_SOCK bind_addr="10.120.180.64" bind_interface="eth10"/>
<FD_ALL/>
<VERIFY_SUSPECT bind_addr="10.120.180.64" bind_interface="eth10" timeout="1500"/>
<pbcast.NAKACK discard_delivered_msgs="false" exponential_backoff="150" gc_lag="0" retransmit_timeout="300,600,1200" use_mcast_xmit="true" use_stats_for_retransmission="false"/>
<UNICAST timeout="300,600,1200"/>
<pbcast.STABLE desired_avg_gossip="50000" max_bytes="4M" stability_delay="1000"/>
<pbcast.GMS join_timeout="5000" print_local_addr="true" view_bundling="true"/>
<UFC max_credits="2M" min_threshold="0.4"/>
<MFC max_credits="2M" min_threshold="0.4"/>
<FRAG2 frag_size="60K"/>
<pbcast.STREAMING_STATE_TRANSFER bind_addr="10.120.180.64" bind_interface="eth10" bind_port="7810" socket_buffer_size="16384" use_default_transport="false"/>
</config>
Have you ever heard about NIC teaming problems ?
Thanks.
Pascal BROUWET
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (JGRP-1533) Two JGoup Server can't communicate each other with multicast
by zhan xuguang (JIRA)
zhan xuguang created JGRP-1533:
----------------------------------
Summary: Two JGoup Server can't communicate each other with multicast
Key: JGRP-1533
URL: https://issues.jboss.org/browse/JGRP-1533
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.6.12
Environment: jgroups-all-2.6.12.jar
cat /proc/version
Linux version 2.6.18-128.el5 (mockbuild(a)builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Jan 21 10:41:14 EST 2009
Reporter: zhan xuguang
Assignee: Bela Ban
precondtion
we have two server Ip1 and Ip2 as a cluster , we used JGOUP as the sync cache channel. these days we find it not workable as it not sync data with
config:
to enable multi-machine synchronization, set the following to true
we are multicasting on 235.11.17.19 port 32765. For information about
<jgroupsInit>
<![CDATA[
UDP(mcast_addr=239.190.1.1;mcast_port=32986;discard_incompatible_packets=true;enable_diagnostics=false;
bind_addr=ip1;
max_bundle_size=60000;max_bundle_timeout=30;ip_ttl=32;enable_bundling=true;
use_concurrent_stack=true;thread_pool.enabled=true;thread_pool.min_threads=1;
thread_pool.max_threads=25;thread_pool.keep_alive_time=5000;
thread_pool.queue_enabled=false;thread_pool.queue_max_size=100;
thread_pool.rejection_policy=Run;oob_thread_pool.enabled=true;oob_thread_pool.min_threads=1;
oob_thread_pool.max_threads=8;oob_thread_pool.keep_alive_time=5000;oob_thread_pool.queue_enabled=false;
oob_thread_pool.queue_max_size=100;oob_thread_pool.rejection_policy=Run):
PING(timeout=2000;num_initial_members=3):
MERGE2(max_interval=30000;min_interval=10000):
FD_SOCK:FD(timeout=10000;max_tries=5;shun=true):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(use_mcast_xmit=false;gc_lag=0;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true):
UNICAST(timeout=300,600,1200,2400,3600):
pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000):
pbcast.GMS(print_local_addr=true;join_timeout=3000;shun=false;view_bundling=true):
FC(max_credits=20000000;min_threshold=0.10):
FRAG2(frag_size=60000):pbcast.STATE_TRANSFER
]]>
</jgroupsInit>
another server same config
<jgroupsInit>
<![CDATA[
UDP(mcast_addr=239.190.1.1;mcast_port=32986;discard_incompatible_packets=true;enable_diagnostics=false;
bind_addr=ip2;
max_bundle_size=60000;max_bundle_timeout=30;ip_ttl=32;enable_bundling=true;
use_concurrent_stack=true;thread_pool.enabled=true;thread_pool.min_threads=1;
thread_pool.max_threads=25;thread_pool.keep_alive_time=5000;
thread_pool.queue_enabled=false;thread_pool.queue_max_size=100;
thread_pool.rejection_policy=Run;oob_thread_pool.enabled=true;oob_thread_pool.min_threads=1;
oob_thread_pool.max_threads=8;oob_thread_pool.keep_alive_time=5000;oob_thread_pool.queue_enabled=false;
oob_thread_pool.queue_max_size=100;oob_thread_pool.rejection_policy=Run):
PING(timeout=2000;num_initial_members=3):
MERGE2(max_interval=30000;min_interval=10000):
FD_SOCK:FD(timeout=10000;max_tries=5;shun=true):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(use_mcast_xmit=false;gc_lag=0;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true):
UNICAST(timeout=300,600,1200,2400,3600):
pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000):
pbcast.GMS(print_local_addr=true;join_timeout=3000;shun=false;view_bundling=true):
FC(max_credits=20000000;min_threshold=0.10):
FRAG2(frag_size=60000):pbcast.STATE_TRANSFER
]]>
</jgroupsInit>
and we use the test programe test find no message receive at ip2
run at ip1 java -cp jgroups-all-2.6.12.jar org.jgroups.tests.McastSenderTest -mcast_addr 239.190.1.1 -port 32986
run at ip2 java -cp jgroups-all-2.6.12.jar org.jgroups.tests.McastReceiverTest -mcast_addr 239.190.1.1 -port 32986
we check two ips at the same network segment
at when we use the ping from ip1 to ip2, we can get the package with tcpdump
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (AS7-5867) VFS runtime generated class file not loaded
by Debasis Jana (JIRA)
Debasis Jana created AS7-5867:
---------------------------------
Summary: VFS runtime generated class file not loaded
Key: AS7-5867
URL: https://issues.jboss.org/browse/AS7-5867
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Environment: windows 7, java 1.6
Reporter: Debasis Jana
Assignee: David Lloyd
Fix For: 7.1.1.Final
JBOSS explodes the WAR file into some temp vfs folder.
My application generate some class on the runtime which stores in temp/vfs/.../WEB-INF/classes.
When application tries to load that class, it can't.
If I put that class on deployment time which packaged into WAR file only then it can be loaded. How can I load those dynamically generated classes on runtime without packaging into WAR.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (AS7-5868) About javac command using tools.jar
by Debasis Jana (JIRA)
Debasis Jana created AS7-5868:
---------------------------------
Summary: About javac command using tools.jar
Key: AS7-5868
URL: https://issues.jboss.org/browse/AS7-5868
Project: Application Server 7
Issue Type: Clarification
Components: Class Loading
Environment: windows 7, java 1.6
Reporter: Debasis Jana
Assignee: David Lloyd
Fix For: 7.1.1.Final
JAVA_HOME points to jdk home directory.
How do JBOSS server compiles converted JSP servlet and loaded it from temp folder.
If I point JAVA_HOME to jre home then how do JBOSS find that tools.jar to compile JSP class.
Now I am generating report generation java on the fly and my application tries to compile that source using apache ant tool which uses tools.jar.
I able to make find resource by putting tools.jar into WEB-INF/tools.jar and make a changes in sun/jdk module.xml (added javax/annotation/processing).
How sun/jdk module works as it's main folder does not contain any .jar file.
If I try to add dependencies (tools.jar) using modules structure then it shows javax.tool..no found. Then if I make change in sun/jdk module.xml by adding javax/tool..then it shows same error.
Can anyone please make me clarify these concerns.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (AS7-5866) Move ExistingChannelModelControllerClient to controller-client
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5866:
-------------------------------------
Summary: Move ExistingChannelModelControllerClient to controller-client
Key: AS7-5866
URL: https://issues.jboss.org/browse/AS7-5866
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
JConsoleCLIPlugin imports this class, bringing a dependency on jboss-as-controller into the cli module. This class doesn't need to be in controller.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (AS7-5864) Classes of a module cannot get access to the META-INF folder in its own jar/module
by John Wu (JIRA)
John Wu created AS7-5864:
----------------------------
Summary: Classes of a module cannot get access to the META-INF folder in its own jar/module
Key: AS7-5864
URL: https://issues.jboss.org/browse/AS7-5864
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.1.Final
Reporter: John Wu
Assignee: David Lloyd
Currently there is absolutely no mechanism for classes of a module to get access to some META-INF/xyz files in its own jar/module, except are in META-INF/services.
This is a serious impediment when considering the installation of third party libraries as shared libraries (modules) in JBoss AS. Some frameworks may rely upon locating internal descriptors in META-INF, and if the libraries are installed as modules, the descriptors are not accessible to the framework itself. Essentially, there is no way of accessing resources under META-INF unless they are either services, or the library is packaged in the deployment.
This is the un-resolved part of issue [AS7-1928|https://issues.jboss.org/browse/AS7-1928].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months