[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-3510:
--------------------------------
Attachment: DummyConstraint.xls
> Decision table unable to generate rule for row with pattern without constraint
> ------------------------------------------------------------------------------
>
> Key: DROOLS-3510
> URL: https://issues.redhat.com/browse/DROOLS-3510
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.15.0.Final
> Reporter: Andre Piwoni
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: DummyConstraint.xls, MissingConstraint.xls, failingDecisionTable.xlsx
>
>
> When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment.
> Expected rules to be generated:
> {code:java}
> rule "Test_1"
> when
> $factA:FactA(hasSomething == "true")
> $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1))
> then
> insert(X);
> end
> rule "Test_2"
> when
> $factA:FactA(hasSomething == "true")
> $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1))
> then
> insert(X);
> end
> rule "Test_3"
> when
> $factA:FactA()
> $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1))
> then
> insert(Y);
> end
> {code}
> Also, there does not seem an alternative way to generate following rule using decision table:
> {code:java}
> rule "Test"
> when
> $factA:FactA($factsB: listOfFactsB)
> $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1))
> then
> insert(Y);
> end
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2430:
---------------------------
Description:
GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
Also look into routing of entire message _batches_.
Investigate whether this is possible.
was:
GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
Investigate whether this is possible.
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.0
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-2435:
------------------------------------
I was able to reproduce the issue in {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING}}.
I added {{@Test(invocationCount = 100)}} and an {{Uphandler}} that pretends to do some work on the first view:
{code:java}
channel.setUpHandler(new UpHandler() {
boolean hasView = false;
@Override
public Object up(Event evt) {
if (evt.getType() == Event.VIEW_CHANGE && !hasView) {
hasView = true;
try {
Thread.sleep(ThreadLocalRandom.current().nextInt(50));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return null;
}
@Override
public Object up(Message msg) {
return null;
}
});
{code}
> ClientGmsImpl ignores newer view during join
> --------------------------------------------
>
> Key: JGRP-2435
> URL: https://issues.redhat.com/browse/JGRP-2435
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed.
> The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out.
> I added some logs in TP and GMS for debugging, and this is what I see:
> {noformat}
> 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC]
> 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### GmsImpl.handleViewChange() {}
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD]
> 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### The ack for the JOIN_RSP is only sent here
> 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2
> {noformat}
> To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-2435:
------------------------------------
Yes, it's the problem I described in the delta view thread. After looking closer at the logs I realized I have some the delta-view failure as well:
{noformat}
14:52:04,511 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,511 TRACE (ucast-receiver-2,NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,529 TRACE (jgroups-5,NodeC:[]) [UDP] NodeC: received [NodeD to NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,529 DEBUG (ForkThread-3,Test:[]) [GMS] NodeC: installing view [NodeD|1] (2) [NodeD, NodeC]
14:52:04,532 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.Test]
### 2nd view is ignored
14:52:04,532 TRACE (jgroups-4,NodeC:[]) [GMS] GmsImpl ignoring view update [NodeD|2] (3) [NodeD, NodeC, NodeA]
14:52:04,543 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=3], TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,543 TRACE (jgroups-4,NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=3], TP: [cluster=org.infinispan.remoting.transport.Test]
### 3rd view is delta view, can't be restored
14:52:04,543 WARN (jgroups-4,NodeC:[]) [GMS] NodeC: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([NodeD|2]) doesn't match the current view-id ([NodeD|1]); discarding delta view [NodeD|3], ref-view=[NodeD|2], joined=[NodeB]
14:52:04,543 TRACE (jgroups-4,NodeC:[]) [GMS] NodeC: sending request for full view to NodeD
14:52:04,543 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[GET_CURRENT_VIEW], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,544 TRACE (ucast-receiver-2,NodeC:[]) [UDP] Received oob=true internal=true message GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,544 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: received [NodeD to NodeC, 91 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,544 TRACE (jgroups-4,NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test]
### Full 3rd view is also ignored
14:52:04,544 TRACE (jgroups-4,NodeC:[]) [GMS] GmsImpl ignoring view update [NodeD|3] (4) [NodeD, NodeC, NodeA, NodeB]
14:52:04,545 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.Test]
14:52:04,557 TRACE (ForkThread-3,Test:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=6, TP: [cluster=org.infinispan.remoting.transport.Test]
{noformat}
> ClientGmsImpl ignores newer view during join
> --------------------------------------------
>
> Key: JGRP-2435
> URL: https://issues.redhat.com/browse/JGRP-2435
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed.
> The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out.
> I added some logs in TP and GMS for debugging, and this is what I see:
> {noformat}
> 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC]
> 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### GmsImpl.handleViewChange() {}
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD]
> 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### The ack for the JOIN_RSP is only sent here
> 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2
> {noformat}
> To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12972) MP Fault Tolerance - Fault Tolerance is missing logging code when activated
by Miroslav Novak (Jira)
[ https://issues.redhat.com/browse/WFLY-12972?page=com.atlassian.jira.plugi... ]
Miroslav Novak moved WFWIP-286 to WFLY-12972:
---------------------------------------------
Project: WildFly (was: WildFly WIP)
Key: WFLY-12972 (was: WFWIP-286)
Component/s: MP Fault Tolerance
(was: MP Fault Tolerance)
> MP Fault Tolerance - Fault Tolerance is missing logging code when activated
> ---------------------------------------------------------------------------
>
> Key: WFLY-12972
> URL: https://issues.redhat.com/browse/WFLY-12972
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Minor
>
> If MP FT is activated by deployment then INFO log is missing logging code:
> {code}
> 10:18:31,626 INFO [io.smallrye.faulttolerance.HystrixExtension] (MSC service thread 1-1) MicroProfile: Fault Tolerance activated
> {code}
> Logging code should be added.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2383) Remove most attributes from sample configurations
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2383?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2383.
----------------------------
Resolution: Done
> Remove most attributes from sample configurations
> -------------------------------------------------
>
> Key: JGRP-2383
> URL: https://issues.redhat.com/browse/JGRP-2383
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> The sample configs have many attributes, e.g.
> {code:xml}
> <pbcast.NAKACK2 xmit_interval="500"
> xmit_table_num_rows="100"
> xmit_table_msgs_per_row="2000"
> xmit_table_max_compaction_time="30000"
> use_mcast_xmit="true"
> discard_delivered_msgs="true" />
> {code}
> This is bad: if default values are changed, people need to upgrade their configs (which they usually don't!).
> In the above example, the only attribute that's really useful is {{xmit_interval}}, the others can be removed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months