[JBoss JIRA] Created: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
9:18 a.m.
TCPPING fails to connect with different server because sender thread is interrupted too
soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:18 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram commented on JGRP-1233:
-------------------------------------
JGroups configuration:
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups
http://www.jgroups.org/schema/JGroups-2.8.xsd">
<!-- TCP: Core transport protocol. This specifies TCP has the protocol for
actual messaging.
Each member will attempt to bind to port 9800 on all network interfaces and
open a
listening socket on that port. If the port is already in use, it will skip
ahead to
a max of 5. -->
<TCP bind_addr="0.0.0.0" bind_port="9043"
loopback="true"
recv_buf_size="${tcp.recv_buf_size:20M}"
send_buf_size="${tcp.send_buf_size:640K}"
discard_incompatible_packets="true"
max_bundle_size="64K"
max_bundle_timeout="30"
enable_bundling="true"
use_send_queues="true"
sock_conn_timeout="300"
timer.num_threads="4"
thread_pool.enabled="true"
thread_pool.min_threads="1"
thread_pool.max_threads="10"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="false"
thread_pool.queue_max_size="100"
thread_pool.rejection_policy="discard"
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="discard" />
<!-- TCPPING: This is the discovery protocol and is setup to use a list of
well-known hosts
at least one of which is guaranteed to alive to establish the initial
network. For
ReportSource, since the critical pieces are the WebSphere columns, we will
list each
of the WebSphere columns here with their default bind_port address. In the
case
where no WebSphere node is available, the batch processes will simply create
a cluster
that will join the WebSphere node when available (via MERGE2 protocol
below). -->
<TCPPING timeout="3000"
initial_hosts="10.0.7.28[9043]"
port_range="1"
num_initial_members="1"/>
<!-- MERGE2: Merging of members together when conditions cause a split-cluster.
-->
<MERGE2 max_interval="10000"
min_interval="5000"/>
<!-- Failure detection protocol using socket status -->
<FD_SOCK/>
<!-- Failure detection protocol using "ping" message -->
<FD timeout="3000"
max_tries="3"/>
<!-- Suspect (i.e., member is suspected to have left abruptly) verification
-->
<VERIFY_SUSPECT timeout="1500"/>
<!-- These are for reliable communication (NAKACK), Group membership services
(GMS), etc. -->
<pbcast.NAKACK use_mcast_xmit="false" gc_lag="50"
retransmit_timeout="600,1200,2400,4800"
discard_delivered_msgs="true" />
<UNICAST timeout="300,600,1200" />
<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="20000"
max_bytes="10K"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000" />
<FC max_credits="2M"
min_threshold="0.10"/>
<FRAG2 frag_size="60K" />
<pbcast.STREAMING_STATE_TRANSFER/>
<!-- <AUTH auth_class="org.jgroups.auth.MD5Token"-->
<!-- auth_value="testme"-->
<!-- token_hash="MD5"/>-->
</config>
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:20 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram commented on JGRP-1233:
-------------------------------------
Log output:
10:05:52.598 [main] INFO org.jgroups.JChannel - JGroups version: 2.10.0.GA
10:05:52.746 [main] DEBUG o.j.conf.ClassConfigurator - Using jg-magic-map.xml as magic
number file and jg-protocol-ids.xml for protocol IDs
10:05:53.563 [main] DEBUG o.jgroups.protocols.pbcast.GMS - changed role to
org.jgroups.protocols.pbcast.ClientGmsImpl
10:05:53.836 [main] DEBUG org.jgroups.stack.Configurator - set property
TCP.diagnostics_addr to default value /224.0.75.75
10:05:53.848 [main] DEBUG org.jgroups.stack.Configurator - set property FD_SOCK.bind_addr
to default value /10.3.10.184
10:05:53.850 [main] DEBUG org.jgroups.stack.Configurator - set property
VERIFY_SUSPECT.bind_addr to default value /10.3.10.184
10:05:53.870 [main] DEBUG org.jgroups.stack.Configurator - set property
STREAMING_STATE_TRANSFER.bind_addr to default value /10.3.10.184
10:05:53.889 [main] DEBUG org.jgroups.protocols.FRAG2 - received CONFIG event:
{bind_addr=/0.0.0.0}
10:05:53.963 [main] TRACE o.j.protocols.pbcast.STABLE - stable task started
10:05:54.129 [main] TRACE org.jgroups.protocols.TCP - joined /224.0.75.75:7500 on lo
10:05:54.131 [main] TRACE org.jgroups.protocols.TCP - joined /224.0.75.75:7500 on
eth3
10:05:54.131 [main] TRACE org.jgroups.protocols.TCP - joined /224.0.75.75:7500 on
eth6
-------------------------------------------------------------------
GMS: address=deuterognosis-63862, cluster=neo-jgroups, physical address=0.0.0.0:9043
-------------------------------------------------------------------
10:05:54.150 [FD_SOCK server socket acceptor,neo-jgroups,deuterognosis-63862] TRACE
org.jgroups.protocols.FD_SOCK - waiting for client connections on /10.3.10.184:50346
10:05:54.162 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:05:54.165 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:05:54.165 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:05:54.165 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:05:54.171 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:05:54.171 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:05:54.478 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
10:05:54.482 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE o.j.blocks.TCPConnectionMap
- [0.0.0.0:9043] accepted connection from /10.0.7.28:9043
10:05:54.501 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- created socket to 10.0.7.28:9043
10:05:54.501 [Connection.Sender [208.77.255.230:50348 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
Starting TCP connection run() method
10:05:54.502 [Connection.Sender [208.77.255.230:50348 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:05:55.666 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:05:55.666 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:05:55.666 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:05:55.666 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:05:55.667 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:05:55.667 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:05:55.967 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
10:05:55.967 [Connection.Sender [208.77.255.230:50348 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:05:57.158 [main] TRACE org.jgroups.protocols.TCPPING - discovery took 3009 ms:
responses: 0 total (0 servers (0 coord), 0 clients)
10:05:57.158 [main] DEBUG o.jgroups.protocols.pbcast.GMS - initial_mbrs are []
10:05:57.158 [main] DEBUG o.jgroups.protocols.pbcast.GMS - no initial members discovered:
creating group as first member
10:05:57.191 [main] DEBUG o.j.protocols.pbcast.NAKACK -
[setDigest()]
existing digest: []
new digest: deuterognosis-63862: [0 : 0 (0)]
resulting digest: deuterognosis-63862: [0 : 0 (0)]
10:05:57.191 [main] DEBUG o.jgroups.protocols.pbcast.GMS - deuterognosis-63862: view is
[deuterognosis-63862|0] [deuterognosis-63862]
10:05:57.195 [main] DEBUG org.jgroups.protocols.FD_SOCK - VIEW_CHANGE received:
[deuterognosis-63862]
10:05:57.195 [Connection.Sender [208.77.255.230:50348 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
Thread was interrupted!
10:05:57.196 [Connection.Sender [208.77.255.230:50348 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] TRACE TCPConnectionMap$TCPConnection -
TCPConnection.Sender thread terminated at 0.0.0.0:9043
10:05:57.200 [main] TRACE o.j.protocols.pbcast.STABLE - deuterognosis-63862: resetting
digest from NAKACK: [deuterognosis-63862#0]
10:05:57.201 [main] TRACE org.jgroups.protocols.FC - new membership:
[deuterognosis-63862]
10:05:57.201 [main] TRACE org.jgroups.protocols.FC - creditors are []
10:05:57.201 [main] TRACE roupsEventDistributionProvider - Joined: deuterognosis-63862
10:05:57.202 [main] DEBUG o.jgroups.protocols.pbcast.GMS - deuterognosis-63862:
10:05:57.202 [main] DEBUG o.jgroups.protocols.pbcast.GMS - created group (first member).
My view is [deuterognosis-63862|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
10:06:03.027 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:06:03.027 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:06:03.027 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:03.027 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:03.028 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:06:03.028 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:06:03.328 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
10:06:03.331 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE o.j.blocks.TCPConnectionMap
- [0.0.0.0:9043] accepted connection from /10.0.7.28:9043
10:06:03.332 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- created socket to 10.0.7.28:9043
10:06:03.332 [Connection.Sender [208.77.255.230:50353 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
Starting TCP connection run() method
10:06:03.333 [Connection.Sender [208.77.255.230:50353 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:06:03.964 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: setting latest_local_digest from NAKACK: [deuterognosis-63862#0]
10:06:03.964 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: sending stable msg [deuterognosis-63862#0]
10:06:03.974 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.NAKACK
- sending deuterognosis-63862#1
10:06:03.975 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to null, src=deuterognosis-63862, headers are STABLE: [STABLE_GOSSIP]:
digest is deuterognosis-63862: [0 : 0 (0)], NAKACK: [MSG, seqno=1], TCP:
[channel_name=neo-jgroups]
10:06:03.975 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- looping back message [dst: <null>, src: deuterognosis-63862 (3 headers), size=0
bytes, flags=OOB]
10:06:03.980 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- received [dst: <null>, src: deuterognosis-63862 (3 headers), size=0 bytes,
flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is deuterognosis-63862: [0 : 0
(0)], NAKACK: [MSG, seqno=1], TCP: [channel_name=neo-jgroups]
10:06:03.982 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=0.0.0.0:9043 (141 bytes)
10:06:03.982 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.NAKACK
- deuterognosis-63862: received deuterognosis-63862#1
10:06:03.982 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: handling digest from deuterognosis-63862 (0 votes):
mine: [deuterognosis-63862#0]
other: [deuterognosis-63862#0]
result: [deuterognosis-63862#0]
10:06:03.982 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: sending stability msg (in 859 ms) [deuterognosis-63862#0]
(copy=18384787)
10:06:04.004 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- received [dst: <null>, src: deuterognosis-63862 (3 headers), size=0 bytes,
flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is deuterognosis-63862: [0 : 0
(0)], NAKACK: [MSG, seqno=1], TCP: [channel_name=neo-jgroups]
10:06:04.528 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:06:04.528 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:06:04.528 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:04.528 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:04.529 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:06:04.529 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:06:04.529 [Connection.Sender [208.77.255.230:50353 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:06:04.829 [Timer-1,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
10:06:04.850 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: sending stability msg [deuterognosis-63862#0] (copy=18384787)
10:06:04.850 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.NAKACK
- sending deuterognosis-63862#2
10:06:04.850 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to null, src=deuterognosis-63862, headers are STABLE: [STABILITY]: digest
is deuterognosis-63862: [0 : 0 (0)], NAKACK: [MSG, seqno=2], TCP:
[channel_name=neo-jgroups]
10:06:04.850 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- looping back message [dst: <null>, src: deuterognosis-63862 (3 headers), size=0
bytes, flags=OOB]
10:06:04.850 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=0.0.0.0:9043 (141 bytes)
10:06:04.850 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- received [dst: <null>, src: deuterognosis-63862 (3 headers), size=0 bytes,
flags=OOB], headers are STABLE: [STABILITY]: digest is deuterognosis-63862: [0 : 0 (0)],
NAKACK: [MSG, seqno=2], TCP: [channel_name=neo-jgroups]
10:06:04.851 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.NAKACK
- deuterognosis-63862: received deuterognosis-63862#2
10:06:04.851 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: received stability msg from deuterognosis-63862:
[deuterognosis-63862#0]
10:06:04.851 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.STABLE
- deuterognosis-63862: resetting digest from NAKACK: [deuterognosis-63862#1]
10:06:04.851 [OOB-1,neo-jgroups,deuterognosis-63862] TRACE o.j.protocols.pbcast.NAKACK
- received stable digest deuterognosis-63862: [0 : 0 (0)]
10:06:04.860 [OOB-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- received [dst: <null>, src: deuterognosis-63862 (3 headers), size=0 bytes,
flags=OOB], headers are STABLE: [STABILITY]: digest is deuterognosis-63862: [0 : 0 (0)],
NAKACK: [MSG, seqno=2], TCP: [channel_name=neo-jgroups]
10:06:06.027 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- discovery took 3000 ms: responses: 0 total (0 servers (0 coord), 0 clients)
10:06:06.027 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.MERGE2
- Discovery results:
[deuterognosis-63862]: [deuterognosis-63862|0] [deuterognosis-63862]
10:06:12.538 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:06:12.538 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:06:12.538 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:12.539 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:12.540 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:06:12.540 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:06:12.840 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
10:06:12.840 [Connection.Sender [208.77.255.230:50353 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:06:14.039 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9044
10:06:14.039 [Timer-3,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCPPING
- [FIND_INITIAL_MBRS] sending PING request to 10.0.7.28:9043
10:06:14.039 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9044, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:14.039 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- sending msg to 10.0.7.28:9043, src=deuterognosis-63862, headers are TCPPING: [PING:
type=GET_MBRS_REQ, cluster=neo-jgroups, arg=own_addr=deuterognosis-63862, view id=null,
is_server=false, is_coord=false, logical_name=deuterognosis-63862,
physical_addrs=0.0.0.0:9043], TCP: [channel_name=neo-jgroups]
10:06:14.041 [Timer-4,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9043 (182 bytes)
10:06:14.041 [Connection.Sender [208.77.255.230:50353 -
10.0.7.28:9043],neo-jgroups,deuterognosis-63862] DEBUG TCPConnectionMap$TCPConnection -
value of can run: true
10:06:14.042 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE org.jgroups.protocols.TCP
- dest=10.0.7.28:9044 (182 bytes)
10:06:14.343 [Timer-2,neo-jgroups,deuterognosis-63862] TRACE o.j.b.TCPConnectionMap$Mapper
- failed creating connection to 10.0.7.28:9044
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:20 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram updated JGRP-1233:
--------------------------------
Description:
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
was:
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:20 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram updated JGRP-1233:
--------------------------------
Priority: Critical (was: Major)
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
Priority: Critical
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:11 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1233:
--------------------------------
A bind_addr of 0.0.0.0 doesn't work, use a valid address of an interface.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:11 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Bela Ban updated JGRP-1233:
---------------------------
Priority: Major (was: Critical)
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:34 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram commented on JGRP-1233:
-------------------------------------
Bela, your comment is right. Using a specific network interface fixes everything. A bind
address of 0.0.0.0 I thought meant use all interfaces available. Is this not true? I ask
for my own education.
Thanks
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:38 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1233:
--------------------------------
No, in JGroups the wildcard address 0.0.0.0 doesn't mean anything.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:38 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Bela Ban resolved JGRP-1233.
----------------------------
Resolution: Rejected
works: 0.0.0.0 is not a valid bind_addr
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:41 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram commented on JGRP-1233:
-------------------------------------
When you say that 0.0.0.0 is invalid in jgroups, I take it you are referring to interface
handling withing jgroups. Because in terms of TCP, binding on 0.0.0.0 shows connections
being established and data traveling through them.
Thanks for you prompt help with this.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:43 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram edited comment on JGRP-1233 at 9/16/10 11:42 AM:
---------------------------------------------------------------
When you say that 0.0.0.0 is invalid in jgroups, I take it you are referring to interface
handling withing jgroups. Because in terms of TCP, binding on 0.0.0.0 shows connections
being established and data traveling through them.
Thanks for your prompt help with this.
was (Author: karthik2):
When you say that 0.0.0.0 is invalid in jgroups, I take it you are referring to
interface handling withing jgroups. Because in terms of TCP, binding on 0.0.0.0 shows
connections being established and data traveling through them.
Thanks for you prompt help with this.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:06 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram edited comment on JGRP-1233 at 9/17/10 12:06 PM:
---------------------------------------------------------------
Thanks for your prompt help with this.
was (Author: karthik2):
When you say that 0.0.0.0 is invalid in jgroups, I take it you are referring to
interface handling withing jgroups. Because in terms of TCP, binding on 0.0.0.0 shows
connections being established and data traveling through them.
Thanks for your prompt help with this.
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:08 a.m.
New subject: [JBoss JIRA] Closed: (JGRP-1233) TCPPING fails to connect with different server because sender thread is interrupted too soon?
[
https://jira.jboss.org/browse/JGRP-1233?page=com.atlassian.jira.plugin.sy...
]
Karthik Abram closed JGRP-1233.
-------------------------------
TCPPING fails to connect with different server because sender thread
is interrupted too soon?
---------------------------------------------------------------------------------------------
Key: JGRP-1233
URL: https://jira.jboss.org/browse/JGRP-1233
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Reporter: Karthik Abram
Assignee: Bela Ban
The configuration file I'm using is in the comment below. The log output is below
that. The system works just fine if I run two instances of the program on the same
machine. However, when I run it on different machines (only 1 port is open between them),
I see connection-established, and then I get this in the log:
TRACE TCPConnectionMap$TCPConnection - TCPConnection.Sender thread terminated at
0.0.0.0:9043
Looking at the code, it seems the sender thread gets interrupted before it gets data from
the other program?
We cannot using MPING for discovery in our environment and this is a major issue for us.
The two machines are 10.0.7.28 and deutergnosis. 10.0.7.28 was started first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5211
days inactive
5212
days old
13 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Karthik Abram (JIRA)