jboss-jira October 2014

jboss-jira@lists.jboss.org

1 participants
1476 discussions

[JBoss JIRA] (WFLY-3888) Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3888?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3888: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1145903|https://bugzilla.redhat.com/show_bug.cgi?id=1145903] from POST to MODIFIED > Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly > --------------------------------------------------------------------------------------------- > > Key: WFLY-3888 > URL: https://issues.jboss.org/browse/WFLY-3888 > Project: WildFly > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > All ERROR and WARN messages should show the full timer information, specially the customer timer-information. > This will make it more easy to identify the exact timer in case of an EJB object has multiple timer instances active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-618: --------------------------------------- The APIs have changed somehow, but there is a compatibility layer that should support 5.x style clients Indeed things could be more complicated if you used the internal APIs. Could you please report on the "bugs that accumulate and collect" does not function properly? Some issues have been fixed even recently, but if you can help isolate the problem we will fix it. The CompositeClassLoader has been replaced entirely in Drools 6.x. I can't guarantee that there will be NO lock whatsoever in 6.x, but definitely it will not involve the CompositeClassLoader. Davide > Thread deadlock on org.drools.util.CompositeClassLoader > ------------------------------------------------------- > > Key: DROOLS-618 > URL: https://issues.jboss.org/browse/DROOLS-618 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Environment: drools expert > Reporter: Shashank Agarwal > Assignee: Mark Proctor > Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt > > > Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0 > Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly. > Name: http-54350-Processor15 > State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18 > Name: http-54350-Processor18 > State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15 > Name: http-54350-Processor20 > State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15 > We do not have definite threads to re-produce the issue. > But deadlocks are happening repeatedly on our production. > Regarding out environment details: > 1. We have windows box on which application runs. > 2. The rules used are kept in .drl and .xls formats > 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession(); > 4. Setup a few session globals as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader

by Shashank Agarwal (JIRA)

[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ] Shashank Agarwal commented on DROOLS-618: ----------------------------------------- Upgrade to drools 6.x is difficult as drools have changed the packages names. Also there are some bugs in drools 6.x that accumulate and collect does not function properly in 6.x series so we are uncertain. Also more importantly, is there a reasoning why Deadlock will NOT happen in drools 6.x ? why deadlock happens in 5.6.x ? > Thread deadlock on org.drools.util.CompositeClassLoader > ------------------------------------------------------- > > Key: DROOLS-618 > URL: https://issues.jboss.org/browse/DROOLS-618 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Environment: drools expert > Reporter: Shashank Agarwal > Assignee: Mark Proctor > Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt > > > Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0 > Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly. > Name: http-54350-Processor15 > State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18 > Name: http-54350-Processor18 > State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15 > Name: http-54350-Processor20 > State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15 > We do not have definite threads to re-produce the issue. > But deadlocks are happening repeatedly on our production. > Regarding out environment details: > 1. We have windows box on which application runs. > 2. The rules used are kept in .drl and .xls formats > 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession(); > 4. Setup a few session globals as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-618: --------------------------------------- Unfortunately Drools 5.x and its CompositeClassLoader were never designed, and thus not guaranteed to be completely thread-safe. Any chance you can upgrade to the 6.x series? > Thread deadlock on org.drools.util.CompositeClassLoader > ------------------------------------------------------- > > Key: DROOLS-618 > URL: https://issues.jboss.org/browse/DROOLS-618 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Environment: drools expert > Reporter: Shashank Agarwal > Assignee: Mark Proctor > Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt > > > Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0 > Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly. > Name: http-54350-Processor15 > State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18 > Name: http-54350-Processor18 > State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15 > Name: http-54350-Processor20 > State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15 > We do not have definite threads to re-produce the issue. > But deadlocks are happening repeatedly on our production. > Regarding out environment details: > 1. We have windows box on which application runs. > 2. The rules used are kept in .drl and .xls formats > 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession(); > 4. Setup a few session globals as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3906) Upgrade jboss-rmi-api_1.0_spec

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3906?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3906: ------------------------------ Description: Upgrade to a version which includes JBEE-156 and JBEE-157. (was: Upgrade to a version which includes JBEE-156.) > Upgrade jboss-rmi-api_1.0_spec > ------------------------------ > > Key: WFLY-3906 > URL: https://issues.jboss.org/browse/WFLY-3906 > Project: WildFly > Issue Type: Component Upgrade > Components: IIOP > Reporter: David Lloyd > Assignee: Tomasz Adamski > Fix For: 9.0.0.CR1 > > > Upgrade to a version which includes JBEE-156 and JBEE-157. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-157) Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow()

by David Lloyd (JIRA)

David Lloyd created JBEE-157: -------------------------------- Summary: Improper exception handling in org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow() Key: JBEE-157 URL: https://issues.jboss.org/browse/JBEE-157 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-rmi-api Reporter: David Lloyd Assignee: Shelly McGowan org.jboss.com.sun.corba.se.impl.javax.rmi.PortableRemoteObject#narrow() has a {{catch (Exception error)}} block in it which wraps all exceptions in a {{ClassCastException}}. However, there should be a second catch block which catches {{RuntimeException}} and rethrows them verbatim, in order to avoid confusing incorrect error messages. In particular, you can get a {{ClassCastException}} whose cause is another {{ClassCastException}}. Problem found in 1.0.4.Final; no version for this exists in the JIRA schema however. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

← Newer
1
...
145
146
147
148
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014