[JBoss JIRA] (JGRP-2424) TUNNEL: add port_range attribute
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2424?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2424:
---------------------------
Description: Currently, gossip_router_hosts in TUNNEL is populated by using a fixed port_range of 1. This should be made configurable via a property {{port_range}} (inherited from {{TP}}). (was: Currently, gossip_router_hosts in TUNNEL is populated by using a fixed port_range of 1. This should be made configurable via a property {{port_range}}.)
> TUNNEL: add port_range attribute
> --------------------------------
>
> Key: JGRP-2424
> URL: https://issues.redhat.com/browse/JGRP-2424
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.9
>
>
> Currently, gossip_router_hosts in TUNNEL is populated by using a fixed port_range of 1. This should be made configurable via a property {{port_range}} (inherited from {{TP}}).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2424) TUNNEL: add port_range attribute
by Bela Ban (Jira)
Bela Ban created JGRP-2424:
------------------------------
Summary: TUNNEL: add port_range attribute
Key: JGRP-2424
URL: https://issues.redhat.com/browse/JGRP-2424
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.9
Currently, gossip_router_hosts in TUNNEL is populated by using a fixed port_range of 1. This should be made configurable via a property {{port_range}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4636) Update Scenario Cheatsheet to mention MVEL and Background
by Daniele Zonca (Jira)
[ https://issues.redhat.com/browse/DROOLS-4636?page=com.atlassian.jira.plug... ]
Daniele Zonca updated DROOLS-4636:
----------------------------------
Git Pull Request: https://github.com/kiegroup/drools-wb/pull/1277 (was: https://github.com/kiegroup/drools/pull/2563#)
> Update Scenario Cheatsheet to mention MVEL and Background
> ---------------------------------------------------------
>
> Key: DROOLS-4636
> URL: https://issues.redhat.com/browse/DROOLS-4636
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Affects Versions: 7.27.0.Final
> Reporter: Anna Dupliak
> Assignee: Daniele Zonca
> Priority: Minor
> Labels: CustomerFocus, drools-tools
>
> Update Scenario Cheatsheet for MVEL expression usage.
> h3. Here are some topics that could be mentioned:
> Expressions for Rule based scenarios for simple types
> * Starts from "*#*"
> * Runs for +properties+
> * Runs for +duplicated+ properties
> * Returns the +same+ type as property type in *GIVEN*
> * Returns boolean in *EXPECTED*
> * Receives rule processed value as a *parameter* in *EXPECTED* via keyword "*actualValue*"
> * Applies java.util.Objects.equals(actualValue, expression result) on the expression result if the *EXPECTED* value not a *boolean*
> * Could run any of java function for the project
> * Exports and imports as any other value
> Limitations
> 1. Mvel expression results +not property same+ type - drives scenario +failure, error reason and highlighted+
> Use case:
> User inputs 1/2 to Integer property
> 2.Mvel execution throws +exception+ - drives scenario execution +stopping, failure, error alert+
> Use case:
> User inputs inexistent MVEL function in one of the properties
> 3.Mvel expression +exception stops+ expression +execution+ for all *EXPECT* colons
> Use case:
> User got one of the GIVEN fact expression excepted
> 4.Mvel +cannot be mixed+ with simple expressions in one cell
> Use case:
> For cell inputs :
> {code:java}
> [#4+4,68]
> #actualvalue>1
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2423) NPE during unlock operation
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2423?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2423:
--------------------------------
OK, so I think I may have fixed this... I basically made sure that even null fields don't lead to NPEs.
Try out JGroups-4.1.9-SNAPSHOT and let me know if this works. If not, please feeel free to reopen.
> NPE during unlock operation
> ---------------------------
>
> Key: JGRP-2423
> URL: https://issues.redhat.com/browse/JGRP-2423
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Max Shaposhnyk
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> The following NPE's are appearing in the che.openshift.io production server logs causing the multiple threads to blocking and break down some fuctionality.
> ATM we're unable to clearly reproduce issue on local installations (it happens very rarely on local, but quite frequently on prod server)
> {noformat}
> java.lang.NullPointerException: null
> at org.jgroups.util.Owner.compareTo(Owner.java:59)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:1142)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:942)
> at java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
> at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
> at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
> at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
> at org.jgroups.protocols.Locking$ClientLockTable.addToPendingReleaseRequests(Locking.java:1323)
> at org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:1070)
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:996)
> at org.jgroups.protocols.Locking.down(Locking.java:176)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928)
> at org.jgroups.JChannel.down(JChannel.java:627)
> at org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:167)
> at org.eclipse.che.multiuser.api.distributed.lock.JGroupsWorkspaceLockService$UnlockerImpl.unlock(JGroupsWorkspaceLockService.java:73)
> at org.eclipse.che.commons.lang.concurrent.Unlocker.close(Unlocker.java:38)
> at org.eclipse.che.api.workspace.server.WorkspaceRuntimes.$closeResource(WorkspaceRuntimes.java:314)
> {noformat}
> additional links:
> [1] https://github.com/eclipse/che/issues/15231
> [2] https://issues.redhat.com/browse/JGRP-2299
> [3] https://issues.redhat.com/browse/JGRP-2364
> [4] https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2423) NPE during unlock operation
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2423?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2423.
----------------------------
Resolution: Done
> NPE during unlock operation
> ---------------------------
>
> Key: JGRP-2423
> URL: https://issues.redhat.com/browse/JGRP-2423
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Max Shaposhnyk
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> The following NPE's are appearing in the che.openshift.io production server logs causing the multiple threads to blocking and break down some fuctionality.
> ATM we're unable to clearly reproduce issue on local installations (it happens very rarely on local, but quite frequently on prod server)
> {noformat}
> java.lang.NullPointerException: null
> at org.jgroups.util.Owner.compareTo(Owner.java:59)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:1142)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:942)
> at java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
> at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
> at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
> at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
> at org.jgroups.protocols.Locking$ClientLockTable.addToPendingReleaseRequests(Locking.java:1323)
> at org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:1070)
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:996)
> at org.jgroups.protocols.Locking.down(Locking.java:176)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928)
> at org.jgroups.JChannel.down(JChannel.java:627)
> at org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:167)
> at org.eclipse.che.multiuser.api.distributed.lock.JGroupsWorkspaceLockService$UnlockerImpl.unlock(JGroupsWorkspaceLockService.java:73)
> at org.eclipse.che.commons.lang.concurrent.Unlocker.close(Unlocker.java:38)
> at org.eclipse.che.api.workspace.server.WorkspaceRuntimes.$closeResource(WorkspaceRuntimes.java:314)
> {noformat}
> additional links:
> [1] https://github.com/eclipse/che/issues/15231
> [2] https://issues.redhat.com/browse/JGRP-2299
> [3] https://issues.redhat.com/browse/JGRP-2364
> [4] https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4892) in evaluators for type Double does not work with executable model
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-4892:
------------------------------------
Summary: in evaluators for type Double does not work with executable model
Key: DROOLS-4892
URL: https://issues.redhat.com/browse/DROOLS-4892
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.31.0.Final, 7.26.0.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
Attachments: executable-model-DoubleTest.zip
The constraint like the following does not match when using executable model.
{noformat}
rule "Double nnn"
when
f : Fact( doubleVal in ( 100, 200, 300 ) )
then
...
end
{noformat}
This rule can fire if executable model is not used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4893) in evaluators for type Double does not work with executable model
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-4893:
------------------------------------
Summary: in evaluators for type Double does not work with executable model
Key: DROOLS-4893
URL: https://issues.redhat.com/browse/DROOLS-4893
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.26.0.Final, 7.31.0.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
Attachments: executable-model-DoubleTest.zip
The constraint like the following does not match when using executable model.
{noformat}
rule "Double nnn"
when
f : Fact( doubleVal in ( 100, 200, 300 ) )
then
...
end
{noformat}
This rule can fire if executable model is not used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2423) NPE during unlock operation
by Max Shaposhnyk (Jira)
[ https://issues.redhat.com/browse/JGRP-2423?page=com.atlassian.jira.plugin... ]
Max Shaposhnyk commented on JGRP-2423:
--------------------------------------
The propblem here is that this given error is reproducing locally _VERY_ rarely, like 1 time in 3-4 days of active testing. On prod it's more often, but we can't use patched jar-s here...
> NPE during unlock operation
> ---------------------------
>
> Key: JGRP-2423
> URL: https://issues.redhat.com/browse/JGRP-2423
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Max Shaposhnyk
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> The following NPE's are appearing in the che.openshift.io production server logs causing the multiple threads to blocking and break down some fuctionality.
> ATM we're unable to clearly reproduce issue on local installations (it happens very rarely on local, but quite frequently on prod server)
> {noformat}
> java.lang.NullPointerException: null
> at org.jgroups.util.Owner.compareTo(Owner.java:59)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:1142)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:942)
> at java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
> at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
> at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
> at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
> at org.jgroups.protocols.Locking$ClientLockTable.addToPendingReleaseRequests(Locking.java:1323)
> at org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:1070)
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:996)
> at org.jgroups.protocols.Locking.down(Locking.java:176)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928)
> at org.jgroups.JChannel.down(JChannel.java:627)
> at org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:167)
> at org.eclipse.che.multiuser.api.distributed.lock.JGroupsWorkspaceLockService$UnlockerImpl.unlock(JGroupsWorkspaceLockService.java:73)
> at org.eclipse.che.commons.lang.concurrent.Unlocker.close(Unlocker.java:38)
> at org.eclipse.che.api.workspace.server.WorkspaceRuntimes.$closeResource(WorkspaceRuntimes.java:314)
> {noformat}
> additional links:
> [1] https://github.com/eclipse/che/issues/15231
> [2] https://issues.redhat.com/browse/JGRP-2299
> [3] https://issues.redhat.com/browse/JGRP-2364
> [4] https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2423) NPE during unlock operation
by Max Shaposhnyk (Jira)
[ https://issues.redhat.com/browse/JGRP-2423?page=com.atlassian.jira.plugin... ]
Max Shaposhnyk commented on JGRP-2423:
--------------------------------------
I have tried thal locally, adding output as follows:
{code:java}
public void addToPendingReleaseRequests(ClientLock cl) {
if(cl != null) {
String tmp=pending_release_reqs.stream().map(ClientLock::toString).collect(Collectors.joining(", "));
log.info(">>>>>>%s: Pending unlock requests: %s", local_addr, tmp);
log.info(">>>>>>%s: New Clientlock: %s",local_addr, cl.toString());
pending_release_reqs.add(cl);
}
}
{code}
And saw that none of the locks which are already in `pending_release_reqs` are null, neither new lock also not null and their adress fields also not nulls. So it seems quite strange for me. Probably some multithreading issue or something.
> NPE during unlock operation
> ---------------------------
>
> Key: JGRP-2423
> URL: https://issues.redhat.com/browse/JGRP-2423
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Max Shaposhnyk
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.9
>
>
> The following NPE's are appearing in the che.openshift.io production server logs causing the multiple threads to blocking and break down some fuctionality.
> ATM we're unable to clearly reproduce issue on local installations (it happens very rarely on local, but quite frequently on prod server)
> {noformat}
> java.lang.NullPointerException: null
> at org.jgroups.util.Owner.compareTo(Owner.java:59)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:1142)
> at org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:942)
> at java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
> at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
> at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
> at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
> at org.jgroups.protocols.Locking$ClientLockTable.addToPendingReleaseRequests(Locking.java:1323)
> at org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:1070)
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:996)
> at org.jgroups.protocols.Locking.down(Locking.java:176)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928)
> at org.jgroups.JChannel.down(JChannel.java:627)
> at org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:167)
> at org.eclipse.che.multiuser.api.distributed.lock.JGroupsWorkspaceLockService$UnlockerImpl.unlock(JGroupsWorkspaceLockService.java:73)
> at org.eclipse.che.commons.lang.concurrent.Unlocker.close(Unlocker.java:38)
> at org.eclipse.che.api.workspace.server.WorkspaceRuntimes.$closeResource(WorkspaceRuntimes.java:314)
> {noformat}
> additional links:
> [1] https://github.com/eclipse/che/issues/15231
> [2] https://issues.redhat.com/browse/JGRP-2299
> [3] https://issues.redhat.com/browse/JGRP-2364
> [4] https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months