[JBoss JIRA] (DROOLS-498) Memory leak in stateful session after retracting facts
by Vitaly Lomov (JIRA)
Vitaly Lomov created DROOLS-498:
-----------------------------------
Summary: Memory leak in stateful session after retracting facts
Key: DROOLS-498
URL: https://issues.jboss.org/browse/DROOLS-498
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Reporter: Vitaly Lomov
Assignee: Mark Proctor
Priority: Minor
After adding many simple facts into the stateful session and then removing them, the factHandles for the removed facts are still referenced by the session. Eventually getting "java.lang.OutOfMemoryError: GC overhead limit exceeded" with the stack trace (sometimes) similar to DROOLS-411.
Someone on StackOverflow suggested iterating through whatever factHandles remain after deletion and delete those, but I get no factHandles (correct, since I removed all facts).
See screenshot for objects in memory _after_ deleting all facts.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-871) Indentation of multiline text content in standalone.xml keeps increasing on rewrites
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-871?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar closed WFLY-871.
----------------------------
Resolution: Out of Date
This is something subsystem parser should take care of and is not a generic thing server handles.
I am closing this with out of date, as osgi subsystems ware moved to their own project.
> Indentation of multiline text content in standalone.xml keeps increasing on rewrites
> ------------------------------------------------------------------------------------
>
> Key: WFLY-871
> URL: https://issues.jboss.org/browse/WFLY-871
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XML Frameworks
> Reporter: David Bosschaert
> Priority: Minor
>
> The standalone.xml file contains some XML tags that contain multi-line XML text, e.g.:
> {code}<property name="org.jboss.osgi.system.modules">
> org.apache.log4j,
> org.jboss.as.osgi,
> javax.inject.api,
> ...{code}
> The problem is that every automatic rewrite of the standalone.xml (e.g. when you deploy a new thing) the indentation increases from the 2nd line of the text, so after the first rewrite it looks like this:
> {code}<property name="org.jboss.osgi.system.modules">
> org.apache.log4j,
> org.jboss.as.osgi,
> javax.inject.api,
> ...{code}
> after a few deploys it ends up looking like this:
> {code}<property name="org.jboss.osgi.system.modules">
> org.apache.log4j,
> org.jboss.as.osgi,
> javax.inject.api,
> ...{code}
> Pretty ugly :(
> Would be nice if the indentation could be left untouched.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1842) ForkChannel.getFORK(...) is not thread-safe
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1842?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1842:
---------------------------
Fix Version/s: 3.4.5
3.5
> ForkChannel.getFORK(...) is not thread-safe
> -------------------------------------------
>
> Key: JGRP-1842
> URL: https://issues.jboss.org/browse/JGRP-1842
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> If multiple concurrent threads attempt to create a ForkChannel using the same fork stack, and the flag is enabled that attempts to create the FORK protocol if missing - the FORK protocol can inadvertently insert multiple times. There needs to be some thread synchronization between the findProtocol(FORK.class) and protocol creation/insertion.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1842) ForkChannel.getFORK(...) is not thread-safe
by Paul Ferraro (JIRA)
Paul Ferraro created JGRP-1842:
----------------------------------
Summary: ForkChannel.getFORK(...) is not thread-safe
Key: JGRP-1842
URL: https://issues.jboss.org/browse/JGRP-1842
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4.4
Reporter: Paul Ferraro
Assignee: Bela Ban
If multiple concurrent threads attempt to create a ForkChannel using the same fork stack, and the flag is enabled that attempts to create the FORK protocol if missing - the FORK protocol can inadvertently insert multiple times. There needs to be some thread synchronization between the findProtocol(FORK.class) and protocol creation/insertion.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-496) Working rule script in version 5.6.0 does not work in 6.0.1
by Jörgen Risholt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-496?page=com.atlassian.jira.plugin... ]
Jörgen Risholt updated DROOLS-496:
----------------------------------
Attachment: drools-test_6.0.1.tar
This is the same test but with non working 6.0.1
> Working rule script in version 5.6.0 does not work in 6.0.1
> -----------------------------------------------------------
>
> Key: DROOLS-496
> URL: https://issues.jboss.org/browse/DROOLS-496
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Jörgen Risholt
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: drools-test_5.6.0.tar, drools-test_6.0.1.tar
>
>
> When trying a script as shown below we can not get it to work with 6.0.1 but with 5.6.0. There seems to be some relation to the number of facts, the more facts the higher probablity that the 6.0.1 version do not trigger. We have made two simple singelthreaded scenarios that I can upload if wanted.
> The examle has a lot of facts, but we notice that from about 50 it seems that the problam may occur.
> rule "TestRule"
> Person(name == "Name0")
> Person(name == "Name1")
> ....
> Person(name == "Name1000")
> then
> System.out.println("Successfully trigged");
> end
> This is the testcode for 5.6.0.Final (work always):
> package drools_test;
> import org.drools.KnowledgeBase;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> import drools_test.data.Person;
> public class App {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args) {
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("rules.drl",
> App.class), ResourceType.DRL);
> KnowledgeBase kb = kbuilder.newKnowledgeBase();
> StatefulKnowledgeSession session = null;
> try {
> session = kb.newStatefulKnowledgeSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules();
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
> And this is the same code for 6.0.1.Final which always fails:
> package drools_test;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> import drools_test.data.Person;
> public class App
> {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args)
> {
> KieServices kieServices = KieServices.Factory.get();
> KieContainer kContainer = kieServices.getKieClasspathContainer();
> KieSession session = null;
> try {
> session = kContainer.newKieSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules(); // Comment out this line and the rule will fire.
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-496) Working rule script in version 5.6.0 does not work in 6.0.1
by Jörgen Risholt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-496?page=com.atlassian.jira.plugin... ]
Jörgen Risholt updated DROOLS-496:
----------------------------------
Attachment: drools-test_5.6.0.tar
Example of working 5.0.6 implementation
> Working rule script in version 5.6.0 does not work in 6.0.1
> -----------------------------------------------------------
>
> Key: DROOLS-496
> URL: https://issues.jboss.org/browse/DROOLS-496
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Jörgen Risholt
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: drools-test_5.6.0.tar
>
>
> When trying a script as shown below we can not get it to work with 6.0.1 but with 5.6.0. There seems to be some relation to the number of facts, the more facts the higher probablity that the 6.0.1 version do not trigger. We have made two simple singelthreaded scenarios that I can upload if wanted.
> The examle has a lot of facts, but we notice that from about 50 it seems that the problam may occur.
> rule "TestRule"
> Person(name == "Name0")
> Person(name == "Name1")
> ....
> Person(name == "Name1000")
> then
> System.out.println("Successfully trigged");
> end
> This is the testcode for 5.6.0.Final (work always):
> package drools_test;
> import org.drools.KnowledgeBase;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> import drools_test.data.Person;
> public class App {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args) {
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("rules.drl",
> App.class), ResourceType.DRL);
> KnowledgeBase kb = kbuilder.newKnowledgeBase();
> StatefulKnowledgeSession session = null;
> try {
> session = kb.newStatefulKnowledgeSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules();
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
> And this is the same code for 6.0.1.Final which always fails:
> package drools_test;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> import drools_test.data.Person;
> public class App
> {
> private final static int NUMBER_OF_PERSONS = 3000;
> public static void main(String[] args)
> {
> KieServices kieServices = KieServices.Factory.get();
> KieContainer kContainer = kieServices.getKieClasspathContainer();
> KieSession session = null;
> try {
> session = kContainer.newKieSession();
> for (int i = 0; i < NUMBER_OF_PERSONS; ++i) {
> session.insert(new Person(String.format("Name%s", i)));
> session.fireAllRules(); // Comment out this line and the rule will fire.
> }
> session.fireAllRules();
> } finally {
> if (session != null) {
> session.dispose();
> }
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-497) KnowledgeBase's ruleBase is never unlocked when an exception is thrown by executed rules
by Antonio Ruberto (JIRA)
[ https://issues.jboss.org/browse/DROOLS-497?page=com.atlassian.jira.plugin... ]
Antonio Ruberto updated DROOLS-497:
-----------------------------------
Description:
We have a KnowledgeBase that is built application start up from which we constantly create new KnowledgeSession from.
If the execution of one of those sessions throws an exception (i.e. one of the rules in the KnowledgeBase throws an exception for some reason), any subsequent KnowledgeSessions that are created and executed get dead locked. The issue stems from the initInitialFact() method in AbstractWorkingMemory.java as seen below. An exception thrown by the underlying rule causes ruleBase.unlock() to never be reached since the unlock statement is not inside a finally block.
{code}
public void initInitialFact( InternalRuleBase ruleBase, MarshallerReaderContext context ) {
ruleBase.lock();
Object initialFact = InitialFactImpl.getInstance();
ObjectTypeConf otc = this.defaultEntryPoint.getObjectTypeConfigurationRegistry()
.getObjectTypeConf( this.defaultEntryPoint.entryPoint, initialFact );
this.initialFactHandle = ruleBase.getConfiguration().getComponentFactory().getFactHandleFactoryService().newFactHandle(
0, initialFact, 0, otc, this, this.defaultEntryPoint );
final PropagationContext pctx = new PropagationContextImpl( 0,
PropagationContext.ASSERTION,
null,
null ,
initialFactHandle,
0,
0,
defaultEntryPoint.getEntryPoint(),
context );
otc.getConcreteObjectTypeNode().assertObject( this.initialFactHandle, pctx, this );
// ADDED, NOT IN THE ORIGINAL 6.x COMMIT
pctx.evaluateActionQueue( this );
ruleBase.unlock();
}
{code}
was:
We have a KnowledgeBase that is built application start up from which we constantly create new KnowledgeSession from.
If the execution of one of those sessions throws an exception (i.e. one of the rules in the KnowledgeBase throws an exception for some reason), any subsequent KnowledgeSessions that are created and executed get dead locked. The issue stems from the initInitialFact() method in AbstractWorkingMemory.java as seen below. An exception thrown by the underlying rule causes ruleBase.unlock() to never be reached.
{code}
public void initInitialFact( InternalRuleBase ruleBase, MarshallerReaderContext context ) {
ruleBase.lock();
Object initialFact = InitialFactImpl.getInstance();
ObjectTypeConf otc = this.defaultEntryPoint.getObjectTypeConfigurationRegistry()
.getObjectTypeConf( this.defaultEntryPoint.entryPoint, initialFact );
this.initialFactHandle = ruleBase.getConfiguration().getComponentFactory().getFactHandleFactoryService().newFactHandle(
0, initialFact, 0, otc, this, this.defaultEntryPoint );
final PropagationContext pctx = new PropagationContextImpl( 0,
PropagationContext.ASSERTION,
null,
null ,
initialFactHandle,
0,
0,
defaultEntryPoint.getEntryPoint(),
context );
otc.getConcreteObjectTypeNode().assertObject( this.initialFactHandle, pctx, this );
// ADDED, NOT IN THE ORIGINAL 6.x COMMIT
pctx.evaluateActionQueue( this );
ruleBase.unlock();
}
{code}
> KnowledgeBase's ruleBase is never unlocked when an exception is thrown by executed rules
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-497
> URL: https://issues.jboss.org/browse/DROOLS-497
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.6.0.Final
> Reporter: Antonio Ruberto
> Assignee: Mark Proctor
> Attachments: drool-497.zip
>
>
> We have a KnowledgeBase that is built application start up from which we constantly create new KnowledgeSession from.
> If the execution of one of those sessions throws an exception (i.e. one of the rules in the KnowledgeBase throws an exception for some reason), any subsequent KnowledgeSessions that are created and executed get dead locked. The issue stems from the initInitialFact() method in AbstractWorkingMemory.java as seen below. An exception thrown by the underlying rule causes ruleBase.unlock() to never be reached since the unlock statement is not inside a finally block.
> {code}
> public void initInitialFact( InternalRuleBase ruleBase, MarshallerReaderContext context ) {
> ruleBase.lock();
> Object initialFact = InitialFactImpl.getInstance();
> ObjectTypeConf otc = this.defaultEntryPoint.getObjectTypeConfigurationRegistry()
> .getObjectTypeConf( this.defaultEntryPoint.entryPoint, initialFact );
> this.initialFactHandle = ruleBase.getConfiguration().getComponentFactory().getFactHandleFactoryService().newFactHandle(
> 0, initialFact, 0, otc, this, this.defaultEntryPoint );
> final PropagationContext pctx = new PropagationContextImpl( 0,
> PropagationContext.ASSERTION,
> null,
> null ,
> initialFactHandle,
> 0,
> 0,
> defaultEntryPoint.getEntryPoint(),
> context );
> otc.getConcreteObjectTypeNode().assertObject( this.initialFactHandle, pctx, this );
> // ADDED, NOT IN THE ORIGINAL 6.x COMMIT
> pctx.evaluateActionQueue( this );
> ruleBase.unlock();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1841) Static discovery protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1841:
---------------------------
Description:
A new protocol similar to {{FILE_PING}} (perhaps a subclass?) which lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
The file could be located on a (shared) file system, S3, a DB table or a cloud store.
*This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{JDBC_PING}} etc.*
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
was:
A new protocol which lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> Static discovery protocol
> -------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A new protocol similar to {{FILE_PING}} (perhaps a subclass?) which lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> The file could be located on a (shared) file system, S3, a DB table or a cloud store.
> *This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{JDBC_PING}} etc.*
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1841) Static discovery protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1841:
---------------------------
Description:
A new protocol which lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
was:
A new protocol which lists *all* members in the following format:
|| Logical name || UUID || IP address:port ||
| A | 1 | 192.168.1.5:7800 |
| B | 2 | 192.168.1.6:7800 |
| C | 3 | 192.168.1.7:7800 |
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed, so we can ping the first nodes for coordinatorship.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> Static discovery protocol
> -------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A new protocol which lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month