[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2227:
--------------------------------
This was resolved in 4.0.12, try that version, _not_ 4.0.8!
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2266?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2266.
----------------------------
Resolution: Done
> RouterStubManager.run() endless reconnect loop burning a CPU
> ------------------------------------------------------------
>
> Key: JGRP-2266
> URL: https://issues.jboss.org/browse/JGRP-2266
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes.
> Reporter: Emmeran Seehuber
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: cs_stack.xml
>
>
> RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU.
> E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down.
> No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up?
> As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2266?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2266:
--------------------------------
I didn't only remove the loop, but the reconnect task is also cancelled when there are no stubs to reconnect to in {{reconnect_list}}.
> RouterStubManager.run() endless reconnect loop burning a CPU
> ------------------------------------------------------------
>
> Key: JGRP-2266
> URL: https://issues.jboss.org/browse/JGRP-2266
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes.
> Reporter: Emmeran Seehuber
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: cs_stack.xml
>
>
> RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU.
> E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down.
> No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up?
> As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2262:
--------------------------------
No, I usually wait for a few JIRAs to accumulate or a few weeks' time, and then release. For the time being, I suggest build your own temp 6.3.16 release.
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Pietro Paolini commented on JGRP-2262:
--------------------------------------
Thanks ! Are you about to push a new release out straight away ?
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2262:
--------------------------------
Testsuite passed OK. Committed and pushed changes to the 3.6 branch.
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (DROOLS-2509) Executable model isn't generated correctly for from clause in the form func(x)
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-2509:
-----------------------------------
Summary: Executable model isn't generated correctly for from clause in the form func(x)
Key: DROOLS-2509
URL: https://issues.jboss.org/browse/DROOLS-2509
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Luca Molteni
Executable model is generated correctly when the from clause is in the form x.func() but not when it is func(x). See the reproducer below
{code}
public static Integer getLength(String s) {
return s.length();
}
@Test
public void testFromExternalFunction() {
final String str =
"import " + FromTest.class.getCanonicalName() + ";\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" $s : String()\n" +
" $i : Integer( this > 10 ) from FromTest.getLength($s)\n" +
"then\n" +
" list.add( \"received long message: \" + $s);\n" +
"end\n";
KieSession ksession = getKieSession( str );
final List<String> list = new ArrayList<>();
ksession.setGlobal( "list", list );
ksession.insert("Hello World!");
ksession.fireAllRules();
Assertions.assertThat(list).containsExactlyInAnyOrder("received long message: Hello World!");
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (DROOLS-2509) Executable model isn't generated correctly for from clause in the form func(x)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2509?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2509:
--------------------------------
Description:
Executable model is generated correctly when the from clause is in the form x.func() but not when it is func( x ). See the reproducer below
{code}
public static Integer getLength(String s) {
return s.length();
}
@Test
public void testFromExternalFunction() {
final String str =
"import " + FromTest.class.getCanonicalName() + ";\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" $s : String()\n" +
" $i : Integer( this > 10 ) from FromTest.getLength($s)\n" +
"then\n" +
" list.add( \"received long message: \" + $s);\n" +
"end\n";
KieSession ksession = getKieSession( str );
final List<String> list = new ArrayList<>();
ksession.setGlobal( "list", list );
ksession.insert("Hello World!");
ksession.fireAllRules();
Assertions.assertThat(list).containsExactlyInAnyOrder("received long message: Hello World!");
}
{code}
was:
Executable model is generated correctly when the from clause is in the form x.func() but not when it is func(x). See the reproducer below
{code}
public static Integer getLength(String s) {
return s.length();
}
@Test
public void testFromExternalFunction() {
final String str =
"import " + FromTest.class.getCanonicalName() + ";\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" $s : String()\n" +
" $i : Integer( this > 10 ) from FromTest.getLength($s)\n" +
"then\n" +
" list.add( \"received long message: \" + $s);\n" +
"end\n";
KieSession ksession = getKieSession( str );
final List<String> list = new ArrayList<>();
ksession.setGlobal( "list", list );
ksession.insert("Hello World!");
ksession.fireAllRules();
Assertions.assertThat(list).containsExactlyInAnyOrder("received long message: Hello World!");
}
{code}
> Executable model isn't generated correctly for from clause in the form func(x)
> ------------------------------------------------------------------------------
>
> Key: DROOLS-2509
> URL: https://issues.jboss.org/browse/DROOLS-2509
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Luca Molteni
>
> Executable model is generated correctly when the from clause is in the form x.func() but not when it is func( x ). See the reproducer below
> {code}
> public static Integer getLength(String s) {
> return s.length();
> }
> @Test
> public void testFromExternalFunction() {
> final String str =
> "import " + FromTest.class.getCanonicalName() + ";\n" +
> "global java.util.List list\n" +
> "\n" +
> "rule R when\n" +
> " $s : String()\n" +
> " $i : Integer( this > 10 ) from FromTest.getLength($s)\n" +
> "then\n" +
> " list.add( \"received long message: \" + $s);\n" +
> "end\n";
> KieSession ksession = getKieSession( str );
> final List<String> list = new ArrayList<>();
> ksession.setGlobal( "list", list );
> ksession.insert("Hello World!");
> ksession.fireAllRules();
> Assertions.assertThat(list).containsExactlyInAnyOrder("received long message: Hello World!");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-10286) Consider to add secmgr options to CLI and JDR
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-10286?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise updated WFLY-10286:
----------------------------------------
Issue Type: Feature Request (was: Bug)
> Consider to add secmgr options to CLI and JDR
> ---------------------------------------------
>
> Key: WFLY-10286
> URL: https://issues.jboss.org/browse/WFLY-10286
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, Scripts
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
>
> Wildfly standalone/domain/appclient scripts allows two ways for start EAP with security manager:
> * -secmgr command line argument ({{./standalone.sh -secmgr}})
> ** This is described in documentation only in Configuration guide in "A.1. Server Runtime Arguments"
> * SECMGR=true env property
> ** This is not described in documentation at all.
> Does it make sence to add secmgr parameter to CLI script? CLI allows to start embedded server, and standalone.sh (non-embedded server) script has the secmgr option. Does it make sence to add secmgr parameter to the jdr script too? JDR tool uses embedded cli server too in some cases.
> Cc: [~eduda], [~mnovak])
> See [this my command|https://issues.jboss.org/browse/WFLY-10242?focusedCommentId=13561...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months