[JBoss JIRA] (JGRP-1529) RELAY2: Intra-site view not being accepted upon inter-site installation failure
by Radim Vansa (JIRA)
Radim Vansa created JGRP-1529:
---------------------------------
Summary: RELAY2: Intra-site view not being accepted upon inter-site installation failure
Key: JGRP-1529
URL: https://issues.jboss.org/browse/JGRP-1529
Project: JGroups
Issue Type: Bug
Reporter: Radim Vansa
Assignee: Bela Ban
When a node becomes coordinator, it sends the VIEW_CHANGE event up the stack. This should result in Receiver.viewAccepted(...) method call. However, when RELAY2 is in stack and the coordinator cannot be reached, it blocks the thread (sending discovery pings) and, therefore, the viewAccepted event is postponed.
In my opinion the inter-site stack should be created and handled in different thread.
Context:
In my case, the coordinator for both local cluster and the global (inter-site) cluster was killed. The FD_SOCK on inter-site stack somehow failed to notice that the coordinator has crashed (more investigation required) and the nodes in global cluster still reported the crashed node as the global coordinator.
Therefore, the new coordinator of local cluster failed to join the global cluster (obviously got no response from the dead global coordinator).
The restarted node joined the local cluster and then tried to join the local Infinispan cache with a new local view ID. However, the coordinator failed to notice (in Infinispan viewAccepted handler which was not called) that he had already installed a new JGroups view and it did not respond to the cache join request because it was waiting until it got the new JGroups view (again, which was installed in JGroups but the viewAccepted did not notified Infinispan about that).
--
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
13 years, 6 months
[JBoss JIRA] (JGRP-1528) RELAY2: batch messages forwarded to remote sites
by Bela Ban (JIRA)
Bela Ban created JGRP-1528:
------------------------------
Summary: RELAY2: batch messages forwarded to remote sites
Key: JGRP-1528
URL: https://issues.jboss.org/browse/JGRP-1528
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
If a site is down, then forwarding a message to it will block the thread (actually: wait) for max_forward_attempts * forward_sleep milliseconds.
If we have many incoming messages (from the local site) to be forwarded to the remote site, then having every thread sleep for (say) 10 seconds will increase the thread pool.
We should therefore add *batching* to RELAY2; messages to be forwarded are queued until a certain time has elapsed or the accumulated total size of all queued messages exceeds a certain threshold.
Incoming messages to be forwarded would be added to the queue (allowing the sending thread to be returned to the thread pool). A separate thread (or task) would monitor the queue and do the forwarding, and it would also notice that a site is down and send unreachable messages back to the original senders.
--
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
13 years, 6 months
[JBoss JIRA] (AS7-5870) Services should only be created when the resource adapter is activated
by Jesper Pedersen (JIRA)
Jesper Pedersen created AS7-5870:
------------------------------------
Summary: Services should only be created when the resource adapter is activated
Key: AS7-5870
URL: https://issues.jboss.org/browse/AS7-5870
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.3.Final (EAP)
Reporter: Jesper Pedersen
Assignee: Stefano Maestri
Priority: Critical
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
The ResourceAdapterDeploymentService class creates services for the resource adapter deployment even though the resource adapter isn't activated
--
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
13 years, 6 months
[JBoss JIRA] (AS7-5863) simplified dmr format parser doesn't support '\' linebreaks
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created AS7-5863:
--------------------------------------
Summary: simplified dmr format parser doesn't support '\' linebreaks
Key: AS7-5863
URL: https://issues.jboss.org/browse/AS7-5863
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.1.3.Final (EAP)
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
The following fails because the simplified format parser doesn't know how to handle '\' linebreaks.
/subsystem=security/security-domain=DemoAuthRealm/authentication=classic:add( \
login-modules=[ \
{ \
code=Database, \
flag=required, \
module-options=[ \
unauthenticatedIdentity=guest, \
dsJndiName=java:jboss/jdbc/ApplicationDS, \
principalsQuery=select password from users where username=?, \
rolesQuery = "select name, 'Roles' FROM user_roless ur, roles r, user u WHERE u.username=? and u.id = ur.user_id and ur.role_id = r.id", \
hashAlgorithm = MD5, \
hashEncoding = hex) \
] \
} \
] \
)
--
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
13 years, 6 months
[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
13 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
13 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
13 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
13 years, 6 months