[JBoss JIRA] Created: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
2:59 a.m.
When a new member joins a group and requests the cache from the coordinator, it always
fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:59 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
[ http://jira.jboss.com/jira/browse/JGRP-550?page=all ]
Dipak Kothari updated JGRP-550:
-------------------------------
Attachment: example.zip
Example code to show the behaviour.
When a new member joins a group and requests the cache from the
coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:06 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
[ http://jira.jboss.com/jira/browse/JGRP-550?page=all ]
Bela Ban updated JGRP-550:
--------------------------
Fix Version/s: 2.5
When a new member joins a group and requests the cache from the
coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Fix For: 2.5
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:56 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
[ http://jira.jboss.com/jira/browse/JGRP-550?page=comments#action_12368353 ]
Bela Ban commented on JGRP-550:
-------------------------------
Works for me. The important thing is to make sure the (2, in my case) members actually
find each other: check the group membership as shown below:
13:53:01,843 [DEBUG] [main] SimpleExample.runTestReplicatedHashMap(): Group membership =
2
Also make sure you have a correct bind_addr (or -Djgroups.bind_addr) in TCP and hostname
for initial_hosts in TCPPING, as shown in my config (running on 192.168.5.2):
<TCP bind_addr="192.168.5.2"
start_port="9800"
loopback="true"
discard_incompatible_packets="true"
use_send_queues="false"
max_bundle_size="64000"
max_bundle_timeout="30"
enable_bundling="true"
sock_conn_timeout="300"
skip_suspected_members="true"
use_concurrent_stack="true"
thread_pool.enabled="true"
thread_pool.min_threads="1"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
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="16"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="true"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run"
/>
<TCPPING
timeout="3000"
initial_hosts="192.168.5.2[9800]"
num_initial_members="2"
port_range="3"/>
When a new member joins a group and requests the cache from the
coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Fix For: 2.5
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:57 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
[ http://jira.jboss.com/jira/browse/JGRP-550?page=comments#action_12368354 ]
Bela Ban commented on JGRP-550:
-------------------------------
Your logs indicate that "localhost" (in TCPPING) might point to 127.0.0.1, which
will cause the members not to find each other.
My startup params were:
java -Dlog4j.configuration=file:c:\log4j.properties -Djgroups.bind_addr=192.168.5.2
jgroup.example.SimpleExample one
When a new member joins a group and requests the cache from the
coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Fix For: 2.5
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:59 a.m.
New subject: [JBoss JIRA] Closed: (JGRP-550) When a new member joins a group and requests the cache from the coordinator, it always fails first time
[ http://jira.jboss.com/jira/browse/JGRP-550?page=all ]
Bela Ban closed JGRP-550.
-------------------------
Resolution: Cannot Reproduce Bug
When a new member joins a group and requests the cache from the
coordinator, it always fails first time
-------------------------------------------------------------------------------------------------------
Key: JGRP-550
URL: http://jira.jboss.com/jira/browse/JGRP-550
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Environment: Example code was run on Windows
Reporter: Dipak Kothari
Assigned To: Bela Ban
Fix For: 2.5
Attachments: example.zip
Service A starts - becomes coordinator. After it has started properly, Service B is
started. As part of the Join, it
1) Gets the members using TCPPING
2) Determines the coordinator
3) Joins
4) Applies view change via the installView. This re-adjusts the members and closes any
connections that are no longer members (so the connection to service A is removed).
5) Requests the cache from the coordinator. Service A on response to this tries to send
the cache but fails as peer connection has been closed. It tries twice and removes
connection. Service B timeout and tries again and this time it is successful. This
happens each time. I don't think this should happen - it should return the cache as
it knowns where it needs to be sent to.
I have added additional trace statements (these start with APM:) to show the flow for my
understanding. I have deliberately set the get_cache_timeout to a high number to
highlight this. I have also provided source and protocol properties in the zip for
convenience. There are 2 logs from the run I carried out: cord.log is the coordinator log
and cord1.log is second services' log.
Please let me know if there is a work around or a fix I can apply. If I have
mis-configured the properties then please advise how to rectify it.
To run the example, run the bat script passing in the service name. Note, the service
name needs to be unique as the log name is based on this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6295
days inactive
6295
days old
5 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Dipak Kothari (JIRA)