9:27 a.m.
Bela Ban created JGRP-1541:
------------------------------
Summary: Discovery: persist discovery responses
Key: JGRP-1541
URL: https://issues.jboss.org/browse/JGRP-1541
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When we use TCPPING.initial_hosts=A, and have nodes A, B and C, then the following can
happen:
- A is started. The view is {A}
- B is started, finds A and joins the cluster. The view is {A,B}
- C is started, finds A and joins the cluster. The view is now {A,B,C}
- A is killed. The view is now {B,C}
- C is restarted
--> C won't find A therefore cannot ask B to join it (C doesn't know about B)
SOLUTION:
- If every member persisted its discovery results on disk, C would still know about A and
B, and could therefore discover B
- This could be implemented directly in TCPPING, or as a generic, separate, protocol
(possibly useful for other discovery protocols such as S3_PING, TCPGOSSIP (when the
GossipRouter is down) as well)
- The disk cache would have to include an expiry mechanism, so that the file doesn't
grow forever, and also stale results aren't returned forever
- This mechanism would not work though if C came up the first time (no file on disk yet)
and A wasn't running.
--
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
10:33 p.m.
[
https://issues.jboss.org/browse/JGRP-1541?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1541:
------------------------------------
For what it's worth, I have implemented more or less this scheme at the application
level.
I doubt that it would have helped me if JGroups already offered this function - because I
store a little more (application-level) information about known nodes than just their
address.
So perhaps this isn't very helpful input: you could reasonably take it either as
evidence that there is demand for such function, or as evidence that there's no need
for it and an application-layer solution is OK. But I thought I would let you know.
Happy to answer questions, if you have any, about the details of what I've done.
Discovery: persist discovery responses
--------------------------------------
Key: JGRP-1541
URL: https://issues.jboss.org/browse/JGRP-1541
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When we use TCPPING.initial_hosts=A, and have nodes A, B and C, then the following can
happen:
- A is started. The view is {A}
- B is started, finds A and joins the cluster. The view is {A,B}
- C is started, finds A and joins the cluster. The view is now {A,B,C}
- A is killed. The view is now {B,C}
- C is restarted
--> C won't find A therefore cannot ask B to join it (C doesn't know about B)
SOLUTION:
- If every member persisted its discovery results on disk, C would still know about A and
B, and could therefore discover B
- This could be implemented directly in TCPPING, or as a generic, separate, protocol
(possibly useful for other discovery protocols such as S3_PING, TCPGOSSIP (when the
GossipRouter is down) as well)
- The disk cache would have to include an expiry mechanism, so that the file doesn't
grow forever, and also stale results aren't returned forever
- This mechanism would not work though if C came up the first time (no file on disk yet)
and A wasn't running.
--
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
8:47 a.m.
[
https://issues.jboss.org/browse/JGRP-1541?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1541:
--------------------------------
Hi David,
I implemented this because there is a real-world use case for it in conjunction with the
xsite replication feature (RELAY2) which can't list all possible hosts in
TCPPING.initial_hosts. This cannot be done at the application level.
PDC only stores (1) logical address, (2) physical address and (3) logical name (the latter
is not really needed for correct operation though). Yes, if you need to store app-specific
information, then you'd have to resort to an application-level protocol.
If you want to take a look at PDC, I'm always happy to get feedback.
Discovery: persist discovery responses
--------------------------------------
Key: JGRP-1541
URL: https://issues.jboss.org/browse/JGRP-1541
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When we use TCPPING.initial_hosts=A, and have nodes A, B and C, then the following can
happen:
- A is started. The view is {A}
- B is started, finds A and joins the cluster. The view is {A,B}
- C is started, finds A and joins the cluster. The view is now {A,B,C}
- A is killed. The view is now {B,C}
- C is restarted
--> C won't find A therefore cannot ask B to join it (C doesn't know about B)
SOLUTION:
- If every member persisted its discovery results on disk, C would still know about A and
B, and could therefore discover B
- This could be implemented directly in TCPPING, or as a generic, separate, protocol
(possibly useful for other discovery protocols such as S3_PING, TCPGOSSIP (when the
GossipRouter is down) as well)
- The disk cache would have to include an expiry mechanism, so that the file doesn't
grow forever, and also stale results aren't returned forever
- This mechanism would not work though if C came up the first time (no file on disk yet)
and A wasn't running.
--
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
9:37 a.m.
New subject: [JBoss JIRA] (JGRP-1541) PDC: persist discovery responses
[
https://issues.jboss.org/browse/JGRP-1541?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1541.
----------------------------
Resolution: Done
PDC: persist discovery responses
--------------------------------
Key: JGRP-1541
URL: https://issues.jboss.org/browse/JGRP-1541
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When we use TCPPING.initial_hosts=A, and have nodes A, B and C, then the following can
happen:
- A is started. The view is {A}
- B is started, finds A and joins the cluster. The view is {A,B}
- C is started, finds A and joins the cluster. The view is now {A,B,C}
- A is killed. The view is now {B,C}
- C is restarted
--> C won't find A therefore cannot ask B to join it (C doesn't know about B)
SOLUTION:
- If every member persisted its discovery results on disk, C would still know about A and
B, and could therefore discover B
- This could be implemented directly in TCPPING, or as a generic, separate, protocol
(possibly useful for other discovery protocols such as S3_PING, TCPGOSSIP (when the
GossipRouter is down) as well)
- The disk cache would have to include an expiry mechanism, so that the file doesn't
grow forever, and also stale results aren't returned forever
- This mechanism would not work though if C came up the first time (no file on disk yet)
and A wasn't running.
--
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
9:37 a.m.
New subject: [JBoss JIRA] (JGRP-1541) PDC: persist discovery responses
[
https://issues.jboss.org/browse/JGRP-1541?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1541:
---------------------------
Summary: PDC: persist discovery responses (was: Discovery: persist discovery
responses)
PDC: persist discovery responses
--------------------------------
Key: JGRP-1541
URL: https://issues.jboss.org/browse/JGRP-1541
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When we use TCPPING.initial_hosts=A, and have nodes A, B and C, then the following can
happen:
- A is started. The view is {A}
- B is started, finds A and joins the cluster. The view is {A,B}
- C is started, finds A and joins the cluster. The view is now {A,B,C}
- A is killed. The view is now {B,C}
- C is restarted
--> C won't find A therefore cannot ask B to join it (C doesn't know about B)
SOLUTION:
- If every member persisted its discovery results on disk, C would still know about A and
B, and could therefore discover B
- This could be implemented directly in TCPPING, or as a generic, separate, protocol
(possibly useful for other discovery protocols such as S3_PING, TCPGOSSIP (when the
GossipRouter is down) as well)
- The disk cache would have to include an expiry mechanism, so that the file doesn't
grow forever, and also stale results aren't returned forever
- This mechanism would not work though if C came up the first time (no file on disk yet)
and A wasn't running.
--
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
4178
days inactive
4179
days old
4 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
David Hotham (JIRA)