[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-623.
--------------------------------
Labels: backport-to-6.0.x (was: )
Fix Version/s: 6.2.0.CR1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/35bb5112d
> Rule with NOT causes excessive firing of the rule
> -------------------------------------------------
>
> Key: DROOLS-623
> URL: https://issues.jboss.org/browse/DROOLS-623
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: Anantjot Anand
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.2.0.CR1
>
> Attachments: TestNotSubnetworkIssue.java
>
>
> Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in
> PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false.
> if (linkedRule && !isRuleLinked()) {
> doUnlinkRule(wm);
> }
> Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2.
> There are two changes that make this issue not appear.
> 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules.
> 2) Removing the NOT clause from R2.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.... ]
Marek Novotny moved JBEAP-87 to WFLY-3937:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-3937 (was: JBEAP-87)
Workflow: GIT Pull Request workflow (was: classic default workflow)
> Jackson libs are Private, should be Public
> ------------------------------------------
>
> Key: WFLY-3937
> URL: https://issues.jboss.org/browse/WFLY-3937
> Project: WildFly
> Issue Type: Bug
> Environment: EAP 6.3.0.ER2
> Reporter: Marek Novotny
>
> The following libraries have their module.xml files set to *private*:
> * org.codehaus.jackson.jackson-core-asl
> * org.codehaus.jackson.jackson-mapper-asl
> * org.codehaus.jackson.jackson-jaxrs
> * org.codehaus.jackson.jackson-xc
> After talking with [~bill.burke], these should be *public*.
> While these modules are private, the use of them creates WARNings in the stack trace.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-623) Rule with NOT causes excessive firing of the rule
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-623?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-623:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Rule with NOT causes excessive firing of the rule
> -------------------------------------------------
>
> Key: DROOLS-623
> URL: https://issues.jboss.org/browse/DROOLS-623
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: Anantjot Anand
> Assignee: Mario Fusco
> Attachments: TestNotSubnetworkIssue.java
>
>
> Debugging of the issue points to De-Activation not able to happen due to RuleExecutor not set dirty upon the call made to BetaNode [line: 369] - doDeleteRightTuple(RightTuple, InternalWorkingMemory, BetaMemory) during reEvaluateNetwork after first time fire of the rule. Further drilling into doDeleteRightTuple indicates memory.unlinkNode(wm) call fails in
> PathMemory.unlinkedSegment as it finds the isRuleLinked() to be false.
> if (linkedRule && !isRuleLinked()) {
> doUnlinkRule(wm);
> }
> Please see the attached junit test case reproducing the issue. There are two rules R1 and R2. R1 sets up criteria needed by R2.
> There are two changes that make this issue not appear.
> 1) Setting the value required by (inside the NOT clause) rule before calling fireAllRules.
> 2) Removing the NOT clause from R2.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-112:
------------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139197|https://bugzilla.redhat.com/show_bug.cgi?id=1139197] from ASSIGNED to MODIFIED
> Long server shut-dow with unresponsive client with opened JNDI Context
> ----------------------------------------------------------------------
>
> Key: WFCORE-112
> URL: https://issues.jboss.org/browse/WFCORE-112
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Miroslav Novak
> Assignee: David Lloyd
> Labels: remoting
> Attachments: JNDIContext.java, testcase.zip
>
>
> Description of problem:
> If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes.
> This scenario takes place, when network connections is lost between JMS clients with JNDI context and server.
> Version-Release number of selected component (if applicable):
> jboss-remoting-3.3.3.Final-redhat-1.jar
> How reproducible:
> always
> Steps to Reproduce:
> 1. Start EAP 6.3.1.CP.CR1 on first machine
> 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java)
> 3. Disconnect network between client and server
> 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c)
> Actual results:
> It takes 15 minutes for server to shutdown.
> Expected results:
> Server should shutdown almost immediately.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-94:
-----------------------------------
Yes it can; after this change, enabling security manager no longer means adding the system (instead the subsystem will always be added). To test with security manager, the -secmgr flag would be given at boot, meaning both core and full can be tested with and without security manager enabled.
> Add -secmgr to startup scripts and propagate -secmgr through the domain
> -----------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-918) Web deployment metrics missing
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-918?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-918:
-------------------------------------
It would be great the metrics provided all the information for mod_cluster integration as well, so that we can get rid of some the wrapping I had to put in here https://github.com/wildfly/wildfly/tree/master/mod_cluster/undertow/src/m...
> Web deployment metrics missing
> ------------------------------
>
> Key: WFLY-918
> URL: https://issues.jboss.org/browse/WFLY-918
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Stefan Negrea
> Assignee: Stuart Douglas
> Labels: rhq
> Fix For: 9.0.0.Beta1
>
>
> The following web deployment metrics are missing from AS7 when compared to AS5 exposed metrics:
> Clustered - True if this web application context is clustered
> Virtual Host - the virtual host with which this context is associated
> Response Time - the minimum, maximum, and average response times for requests serviced by this webapp
> Currently Active Sessions - the number of sessions that are currently active for this WAR
> Maximum Active Sessions - the maximum number of sessions that have been active for this WAR
> Created Sessions - the number of sessions created for this WAR
> Created Sessions per Minute - the number of sessions created for this WAR
> Expired Sessions - the number of expired sessions for this WAR
> Expired Sessions per Minute - the number of expired sessions for this WAR
> Rejected Sessions - the number of sessions rejected for this WAR
> Rejected Sessions per Minute - the number of sessions rejected for this WAR
> Average Session Alive Time - the average alive time of sessions for this WAR
> Max Session Alive Time - the maximum alive time of sessions for this WAR
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFCORE-94:
-----------------------------------
Security manager subsystem is not part of core, but full/web given that is part of EE.
So we cannot include that by default in testsuite / build for core.
> Add -secmgr to startup scripts and propagate -secmgr through the domain
> -----------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2632:
---------------------------------
Workaround Description: (was: Ignore the messages, they will disappear after 1 minute (or the value of UNICAST3.conn_close_timeout).)
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.Beta1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months