[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work around but basically the problem is that the newly written that can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work around but basically the problem is that the newly written that can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work around but basically the problem is that the newly written that can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
!Image1.png|thumbnail!
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
!Image1.png|thumbnail!
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
!Image1.jpg|thumbnail!
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from ON_QA to VERIFIED
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: Filippe Spolti
> Fix For: 2.0.5.CR1
>
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5520) Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5520:
---------------------------------
Due Date: 28/Jan/16
Setting due date in 2 days from now.
> Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5834) NPE handling request to /clusterbench/ejbservlet
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5834?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-5834:
--------------------------------------
Ok, did some investigation on this. So here is the code failing with an NPE:
{code:java}
@Override
public boolean containsLockOrBackupLock(Object key) {
return getLockedKeys().contains(key) || getBackupLockedKeys().contains(key);
}
{code}
And if you look at getBackupLockedKeys() - which is returning 'null', it sounds like (at first glance) that it's impossible for it to be 'null':
{code:java}
@Override
public Set<Object> getBackupLockedKeys() {
return backupKeyLocks == null ?
InfinispanCollections.emptySet() : backupKeyLocks;
}
{code}
Indeed either, the backupKeyLocks are not null, and returned, or the an empy collections is returned. So my assumption here is that backupKeyLocks being volatile, it get "nullified" after passing the check:
{code:java}
/** Holds all the locks for which the local node is a secondary data owner. */
protected volatile Set<Object> backupKeyLocks = null;
{code}
However, this is 1) an assumption (I completly may have misunderstand what happens here) and 2) it does gave a way to fix the issue. I'm thinking adding a synchronized block would fix the issue but it's certainly not worth it. A try-catch to silence the exception would also work, but potentially swallows other issues (and so on).
So IMHO, I'm honestly not sure what to do. I'm guessing, ignoring the issue and moving on maybe the best option here, but maybe someone else (more familliar with both the code base and the product behavior) could have a better idea ?
> NPE handling request to /clusterbench/ejbservlet
> ------------------------------------------------
>
> Key: WFLY-5834
> URL: https://issues.jboss.org/browse/WFLY-5834
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Romain Pelisse
>
> Seen in failover-ejb-ejbservlet-jvmkill-dist-sync scenario.
> 6 seconds after failing perf20 (jvmkill), perf18 logged ISPN000136: Execution error: java.lang.NullPointerException.
> Timeline:
> {code:title=client}
> 2015/11/27 08:23:25:206 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 2 (perf20) is down.
> {code}
> {code:title=perf18}
> [JBossINF] [0m[31m08:23:31,049 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-70) ISPN000136: Execution error: java.lang.NullPointerException
> [JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.containsLockOrBackupLock(AbstractCacheTransaction.java:254)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithLockedKey$177(DefaultPendingLockManager.java:252)
> [JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:284)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithLockedKey(DefaultPendingLockManager.java:249)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:187)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:69)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:76)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:403)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:388)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:412)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:437)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Another NPE followed right after:
> {code}
> [JBossINF] [0m[31m08:23:31,050 ERROR [io.undertow.request] (default task-70) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.containsLockOrBackupLock(AbstractCacheTransaction.java:254)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithLockedKey$177(DefaultPendingLockManager.java:252)
> [JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:284)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithLockedKey(DefaultPendingLockManager.java:249)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:187)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:69)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:76)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:403)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:388)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:412)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:437)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This issue may be related:
> https://issues.jboss.org/browse/WFLY-5208
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-987:
------------------------------------
I believe that this problem is caused by drools/jbpm interaction and in particular by the fact that jbpm is triggering a reentrant flushing of the propagation queue as demonstrated by the following stack trace. We need to figure out if we can avoid this reentrant flushing or even better if we can make it safer.
{code}
org.jbpm.workflow.instance.WorkflowRuntimeException: [droolsTest.RFGAB:47 - :4] -- null
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:179)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.impl.ExtendedNodeInstanceImpl.triggerCompleted(ExtendedNodeInstanceImpl.java:44)
at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:341)
at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:318)
at org.jbpm.workflow.instance.node.RuleSetNodeInstance.signalEvent(RuleSetNodeInstance.java:124)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.signalEvent(WorkflowProcessInstanceImpl.java:490)
at org.jbpm.process.instance.event.DefaultSignalManager.internalSignalEvent(DefaultSignalManager.java:82)
at org.jbpm.process.instance.event.DefaultSignalManager$SignalAction.execute(DefaultSignalManager.java:181)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2003)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.executeQueuedActions(StatefulKnowledgeSessionImpl.java:1548)
at org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74)
at org.jbpm.process.instance.ProcessRuntimeImpl$3.afterRuleFlowGroupDeactivated(ProcessRuntimeImpl.java:458)
at org.drools.core.event.AgendaEventSupport.fireAfterRuleFlowGroupDeactivated(AgendaEventSupport.java:180)
at org.drools.core.common.DefaultAgenda.getNextFocus(DefaultAgenda.java:552)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1341)
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.test.RulesJUnitTest$1.afterRuleFlowGroupActivated(RulesJUnitTest.java:87)
at org.drools.core.event.AgendaEventSupport.fireAfterRuleFlowGroupActivated(AgendaEventSupport.java:152)
at org.drools.core.common.DefaultAgenda.activateRuleFlowGroup(DefaultAgenda.java:707)
at org.drools.core.common.DefaultAgenda.activateRuleFlowGroup(DefaultAgenda.java:695)
at org.jbpm.workflow.instance.node.RuleSetNodeInstance.internalTrigger(RuleSetNodeInstance.java:88)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:73)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:44)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:35)
at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:236)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:439)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:208)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:191)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:183)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:1797)
at org.drools.test.RulesJUnitTest$ThreadAB.run(RulesJUnitTest.java:174)
Caused by: java.lang.NullPointerException
at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:343)
at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:158)
at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:97)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:285)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:256)
at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:351)
at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:333)
at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:357)
at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:173)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2003)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.executeQueuedActions(StatefulKnowledgeSessionImpl.java:1548)
at org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:377)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:384)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.nodeInstanceCompleted(WorkflowProcessInstanceImpl.java:592)
at org.jbpm.workflow.instance.node.EndNodeInstance.internalTrigger(EndNodeInstance.java:72)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
... 41 more
{code}
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Mario Fusco
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-987:
----------------------------------
Assignee: Marco Rietveld (was: Mario Fusco)
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months