[JBoss JIRA] (WFCORE-1272) Clean the deployment Resource in RootDeploymentUnitService's stop() method
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1272:
----------------------------------------
Summary: Clean the deployment Resource in RootDeploymentUnitService's stop() method
Key: WFCORE-1272
URL: https://issues.jboss.org/browse/WFCORE-1272
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, Server
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
DUPs can modify the Resource associated with a deployment in their deploy method, and should, by the DUP contract, reverse that change in undeploy. Scott's WFLY-4908 fix does this, and is good as it means the behavior is correct per the DUP contract.
But as a second line of defense, RootDeploymentUnitService's stop method can clean up the deployment resource using DeploymentResourceSupport.cleanup. This will ensure that if the service is stopped by MSC without an undeploy or redeploy mgmt op being involved, if the service is started again the deployment resource will be back in the state it was when the RDUS was first constructed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1269) Resource passed into RootDeploymentUnitService is decoupled from official model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1269?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1269.
--------------------------------------
Resolution: Won't Do
I've decided not to try and fix this, at least not via keeping this resource in sync.
The problem is for this to work properly, the resource cached in the DeploymentUnit would have to have visibility to unpublished changes being made by subsequently executing ops, not just to the changes made once the subsequent op commits. And making that change would be too problematic
For example, in the WFLY-4908 case an undeploy op affecting deployment 1 is triggering MSC to stop services for deployment 2, and then a later deploy op for deployment one causes MSC to start the services for deployment 2. Neither the undeploy or deploy ops directly relate to deployment 2. But because of the MSC dependency, the deployment 2 DUPs run during both. But the DUP don't have a ref to the currently unpublished resource tree used by those ops.
I'm closing this and am going to open a different issue for a minor change to help avoid the need for things like Scott's WFLY-4908 fix.
> Resource passed into RootDeploymentUnitService is decoupled from official model
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1269
> URL: https://issues.jboss.org/browse/WFCORE-1269
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Server
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
>
> When DeploymentHandlerUtil.doDeploy passes the Resource for the deployment into RootDeploymentUnitService, it is from the currently executing management ops version of the resource tree, and becomes the "official" version once that op commits. But once another config write op commits, the Resource instance cached by the RootDeploymentUnitService and attached by it to the DeplopymentUnit is no longer the official copy; it's a previous copy, aka "cruft". So any mutation to it is not affecting the official copy.
> Where this can be an issue is if the deployment services stop or restart due to MSC dependency changes (i.e. some service depended upon by the deployment stops or restarts), but not due to deploy/undeploy/redeploy ops affecting the deployment directly. The stop/restart will trigger the DUPs which then may attempt the out of date "cruft" Resource.
> WFLY-4908 is an example of such modification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1982 at 1/6/16 10:07 AM:
---------------------------------------------------------
Hmm, we could check whether we find a contiguous amount of free space, and do compaction, e.g.
||0||1||2||3||4||5||6||7||
|0|-|-|-|-|-|-|7|
Here we have an array of capacity=8, with request IDs 0 (at index 0) and 7 (at index 7). We have 6 free array slots available for compaction. We could therefore compact the array to (say) 4 (or even 2):
||0||1||2||3||
|0|-|-|7|
0 mod 4 is index=0 and 7 mod 4 is index=3, so this works as long as we find half of the buffer size more free slots.
The question is _when_ to check if the array can be compacted and determining the minimum number of free slots for compaction...
was (Author: belaban):
Hmm, we could check whether we find a contiguous amount of free space, and do compaction, e.g.
||0||1||2||3||4||5||6||7||
|0|-|-|-|-|-|-|7|
Here we have an array of capacity=8, with request IDs 0 (at index 0) and 7 (at index 7). We have 6 free array slots available for compaction. We could therefore compact the array to (say) 4 (or even 2):
||0||1||2||3||
|0|-|-|7|
0 mod 4 is index=0 and 7 mod 4 is index=3, so this works.
The question is _when_ to check if the array can be compacted and determining the minimum number of free slots for compaction...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (ELY-401) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-401:
------------------------------------
Summary: ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
Key: ELY-401
URL: https://issues.jboss.org/browse/ELY-401
Project: WildFly Elytron
Issue Type: Bug
Components: SSL, Utils
Reporter: Darran Lofthouse
Fix For: 1.1.0.Beta4
Getting the following warning logged when filtering the ciphers available from Oracle Java 8 with unlimited strength policy files in place: -
{noformat}
ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
{noformat}
_The JCE policy is probably unrelated, mentioning it just in case._
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Summary: Support for multiple mod_cluster configurations (load-balancing on multiple ports) (was: wildfly-mod_cluster integration should load-balance requests on more than one ports)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Priority: Trivial
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Priority: Major (was: Trivial)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Affects Version/s: 10.0.0.Final
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Affects Version/s: 8.2.0.Final
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5884) Support for multiple mod_cluster configurations (load-balancing on multiple ports)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5884?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5884:
---------------------------------
Labels: connector listener load-balancing mod_cluster port undertow (was: connector listener load-balancing mod_cluster port undertow wildfly)
> Support for multiple mod_cluster configurations (load-balancing on multiple ports)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5884
> URL: https://issues.jboss.org/browse/WFLY-5884
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: httpd 2.2
> modcluster 1.3.0
> wildfly 8.2.0.Final
> Reporter: kostd kostd
> Assignee: Radoslav Husar
> Labels: connector, listener, load-balancing, mod_cluster, port, undertow
> Attachments: load-balancer-question-scheme.png
>
>
> Earlier I asked on forums https://developer.jboss.org/message/946476#946476
> {quote}
> on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area.
>
> we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304.
>
> In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section:
>
> {code:title=jboss-as-mod-cluster_1_2.xsd}
> <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/>
> {code}
>
> alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304.
> But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both.
>
> Seems that mod_cluster absolutely not supports more than one connector balancing:
>
> {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf}
> Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to
> which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not
> confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector
> can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml,
> mod_cluster uses the following algorithm to choose between them:
> 1. If an native (APR) AJP connector is available, use it.
> 2. If an AJP connector is available, use it.
> 3. Otherwise, choose the HTTP connector with the highest max threads.
> {code}
>
> is this true?
>
> what is the best way to solve our problem?
> {quote}
> During more than 100 views no one answer :'(
> Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1017:
-------------------------------------------------
Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1295433|https://bugzilla.redhat.com/show_bug.cgi?id=1295433] from NEW to MODIFIED
> NPE deleting an expired event in equality mode
> ----------------------------------------------
>
> Key: DROOLS-1017
> URL: https://issues.jboss.org/browse/DROOLS-1017
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> Trying to delete an already expired event in equality mode causes the following NPE in the TMS:
> {code}
> java.lang.NullPointerException
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506)
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months