[JBoss JIRA] (DROOLS-2210) Drools 7.3.0 serialization null pointer exceptions with sliding windows
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2210?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2210:
--------------------------------
Sprint: 2018 Week 05-06, 2018 Week 48-50 (was: 2018 Week 05-06)
> Drools 7.3.0 serialization null pointer exceptions with sliding windows
> -----------------------------------------------------------------------
>
> Key: DROOLS-2210
> URL: https://issues.jboss.org/browse/DROOLS-2210
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.3.0.Final
> Reporter: Manjunath S Paramesan
> Assignee: Mario Fusco
> Priority: Critical
>
> We have a fairly large rule-base with temporal reasoning and sliding windows.
> While serializing the drools session we observe random null pointer exceptions as see below:
> Exception in thread "pool-92-thread-98" java.lang.NullPointerException
> at org.drools.core.rule.SlidingTimeWindow$BehaviorJobContextTimerOutputMarshaller.serialize(SlidingTimeWindow.java:323)
> at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeTimers(ProtobufOutputMarshaller.java:880)
> at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:210)
> at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:118)
> at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:162)
> at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:146)
> at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.backupKieSession(DroolsClientImpl.java:743)
> at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.lambda$processStatefulEvents$0(DroolsClientImpl.java:506)
> at java.lang.Thread.run(Thread.java:745)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-2174) Deadlock between AbstractWorkingMemory and DefaultAgenda
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2174?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2174.
---------------------------------
Resolution: Out of Date
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
> Key: DROOLS-2174
> URL: https://issues.jboss.org/browse/DROOLS-2174
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Reporter: Umang Sharma
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 6.0.0.CR2
>
>
> I am getting a similar deadlock as the one in the cloned issue. We are using following dependencies:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-templates</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.kie</groupId>
> <artifactId>kie-api</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> runtime.version = 6.5.0-Final
> I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> And one of them is stuck in the following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> Please help us out in fixing this. Its a production system serving millions of users.
> PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3347) Implement Undo/Redo
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3347?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3347:
-------------------------------------
Story Points: 4
> Implement Undo/Redo
> -------------------
>
> Key: DROOLS-3347
> URL: https://issues.jboss.org/browse/DROOLS-3347
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Provide actual implementation of undo/redo.
> Step:
> 1) verify that all model modification happen through commands (check "flush" methods inside grid cells and other access to model)
> 2) implement columns size persistence inside backend model (wrap simulation inside another object to store dimension size)
> 3) implement actual undo/redo
> 4) add Undo/Redo buttons
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3347) Implement Undo/Redo
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3347?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3347:
-------------------------------------
Sprint: 2018 Week 45-47
> Implement Undo/Redo
> -------------------
>
> Key: DROOLS-3347
> URL: https://issues.jboss.org/browse/DROOLS-3347
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Provide actual implementation of undo/redo.
> Step:
> 1) verify that all model modification happen through commands (check "flush" methods inside grid cells and other access to model)
> 2) implement columns size persistence inside backend model (wrap simulation inside another object to store dimension size)
> 3) implement actual undo/redo
> 4) add Undo/Redo buttons
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11343) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-11343?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on WFLY-11343:
--------------------------------------
[~kabirkhan] the reason it would be different would be because it would be a semphore and not a reentrant lock. As the comment suggests when either a reaper times out the transaction or the transaction is propagated over a transport medium that uses a thread pool then different threads can end up calling the cancel that don't own the lock.
I was just transferring the suggestion from Stuart, EJB timer code is not my specialism either.
> Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11343
> URL: https://issues.jboss.org/browse/WFLY-11343
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 6.4.18
> Reporter: Shaun Appleton
> Assignee: Tom Jenkinson
> Priority: Major
>
> Description of problem:
> Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
> https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
> Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.
> A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start a JTA/JTS tx and call an EJB timer inside it
> 2. Make the transaction timeout
> 3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
> ---------------------------------------------------------------------------------------------------------
> "Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Locked ownable synchronizers:
> - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> ---------------------------------------------------------------------------------------------------------
> Actual results:
> Lock being held forever
> Expected results:
> Lock getting released
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11405) Remove unused dependencies in org.jboss.as.ee
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11405?page=com.atlassian.jira.plugin... ]
Yeray Borges updated WFLY-11405:
--------------------------------
Summary: Remove unused dependencies in org.jboss.as.ee (was: Remove unused dependencies from org.jboss.as.ee)
> Remove unused dependencies in org.jboss.as.ee
> ---------------------------------------------
>
> Key: WFLY-11405
> URL: https://issues.jboss.org/browse/WFLY-11405
> Project: WildFly
> Issue Type: Bug
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Minor
>
> Analisys shows the following dependencies can be removed from org.jboss.as.ee module:
> {code:java}
> <module name="javax.transaction.api"/>
> <module name="javax.xml.ws.api" optional="true"/>
> {code}
> * There are no direct dependencies to any class managed by those modules from wildfly-ee resource.
> * Those modules are not exporting services that can be loaded by any other class.
> * Although there are some {{getClassLoader().loadClass}} calls in some classes in wildfly-ee.jar, those {{loadClass}} calls are done using the Deployment Unit module class loader, where the removed modules are added by other deployment processors in previous phases.
> One motivation to create this issue is that, in general, be able to remove any unused dependency marked as optional="true" is good for Galleon, because we will be sure that the provision is correct without including those optional dependencies.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11405) Remove unused dependencies from org.jboss.as.ee
by Yeray Borges (Jira)
Yeray Borges created WFLY-11405:
-----------------------------------
Summary: Remove unused dependencies from org.jboss.as.ee
Key: WFLY-11405
URL: https://issues.jboss.org/browse/WFLY-11405
Project: WildFly
Issue Type: Bug
Reporter: Yeray Borges
Assignee: Yeray Borges
Analisys shows the following dependencies can be removed from org.jboss.as.ee module:
{code:java}
<module name="javax.transaction.api"/>
<module name="javax.xml.ws.api" optional="true"/>
{code}
* There are no direct dependencies to any class managed by those modules from wildfly-ee resource.
* Those modules are not exporting services that can be loaded by any other class.
* Although there are some {{getClassLoader().loadClass}} calls in some classes in wildfly-ee.jar, those {{loadClass}} calls are done using the Deployment Unit module class loader, where the removed modules are added by other deployment processors in previous phases.
One motivation to create this issue is that, in general, be able to remove any unused dependency marked as optional="true" is good for Galleon, because we will be sure that the provision is correct without including those optional dependencies.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months