[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGTOOL-71:
---------------------------------
Fix Version/s: 2.1.0.Alpha1
(was: 1.2.2.Final)
> Allow messages to have expressions resolved at code generation time
> -------------------------------------------------------------------
>
> Key: LOGTOOL-71
> URL: https://issues.jboss.org/browse/LOGTOOL-71
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 2.1.0.Alpha1
>
>
> Allow messages in the {{@Message}} annotation to allow expressions in the format of:
> {code}
> ${property.name:default}
> {code}
> A warning message should be generated if the property name was not found. If not default is found an error should be generated.
> The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6415) Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6415?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-6415:
----------------------------------
Assignee: Paul Ferraro (was: Radoslav Husar)
> Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6415
> URL: https://issues.jboss.org/browse/WFLY-6415
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> {code}
> * <p>While this class inherits from {@link ThreadPoolExecutor}, a few
> * of the inherited tuning methods are not useful for it. In
> * particular, because it acts as a fixed-sized pool using
> * {@code corePoolSize} threads and an unbounded queue, adjustments
> * to {@code maximumPoolSize} have no useful effect. Additionally, it
> * is almost never a good idea to set {@code corePoolSize} to zero or
> * use {@code allowCoreThreadTimeOut} because this may leave the pool
> * without threads to handle tasks once they become eligible to run.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated WFLY-6442:
-----------------------------------
Comment: was deleted
(was: The fix will be in 5.3.2.Final which is due for release tomorrow after which I will raise a PR to get it into WildFly.)
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on WFLY-6442:
----------------------------------------
The fix will be in 5.3.2.Final which is due for release tomorrow after which I will raise a PR to get it into WildFly.
> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
> Key: WFLY-6442
> URL: https://issues.jboss.org/browse/WFLY-6442
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final.
> Our test case:
> * enlist activemq JMS resource
> * enlist test XA resource
> * prepare JMS resource
> * prepare test XA resource
> * commit JMS resource
> * commit test XA resource
> ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}}
> 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}
> * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}}
> ** expecting one indoubt participant in HEURISTIC state
> * calling operation {{recovery}} on all transaction's participants
> * do recovery
> This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants.
> Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka commented on WFLY-6413:
----------------------------------------
Looking at it a little bit more, there is actually used Range request processing done as part of {{io.undertow.servlet.handlers.DefaultServlet}}. Where is incorrectly counted {{Content-Range}} header. I have send PR fixing the issue [https://github.com/undertow-io/undertow/pull/375]
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Blocker
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (DROOLS-1059) Drools can't find rules under stress
by Sebastian Schaer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1059?page=com.atlassian.jira.plugi... ]
Sebastian Schaer commented on DROOLS-1059:
------------------------------------------
Hi,
I'm experiencing the same issue as well under a stress test situation:
Seemingly random failures for queries (but they all exist).
We typically run only about 10-20 rules though.
I will try to add more information or work on a reproducer (if I find the time).
Just my observations and an example stacktrace of the error we encounter:
{code}
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | [m java.lang.RuntimeException: Unable to find query 'rule_2f6dc65eb814487eb37acde7c99c2a16_query'
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.387 | at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SegmentUtilities.createChildSegment(SegmentUtilities.java:321) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SegmentUtilities.createChildSegments(SegmentUtilities.java:313) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:186) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:170) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.413 | at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1270) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:107) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:153) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:69) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
INFO | jvm 1 | main | 2016/03/25 18:34:14.414 | at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292) ~[drools-core-6.3.0.Final.jar:6.3.0.Final]
{code}
Unlike [~massinissa] we use stateless sessions and the exception happens when we execute the FireAllRulesCommand.
I also implemented a very simple retry logic (limited to 5 retries) around this specific exception (catching this exception, and reusing the existing stateless session to execute the same command again) and so far I have not encountered any case where the exception gets thrown a second time. And from all I can tell the second time the FireAllRulesCommand is executed, the rule evaluation seems ok (we create/insert facts and all of that seems to be working fine).
(So my preliminary workaround is to just re-execute the same command on the same session and it seems ok so far. This of course might not work with stateful sessions).
> Drools can't find rules under stress
> ------------------------------------
>
> Key: DROOLS-1059
> URL: https://issues.jboss.org/browse/DROOLS-1059
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: DroolsBugReproducerTest.java, reproducerRule.drl
>
>
> In my knowledge base, I have many rules.
> All of them are working very well in production with drools 6.0.1-FINAL even in stress condition hight trafic (arount 40 hits seconds)
> This bug append when we made an upgrade with drools 6.3.0-FINAL which is compatible with jdk8 mandatory in my case.
> So now when I put my rules under stress test (benchmarking) I got this random error.
> Drools is unable to find a query (not always the same one).
> I got this error for 0,6% of my requests.
> *+Following the stack trace : +*
> Unable to find query 'checkAndBindBasket'
> at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:167) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months