August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1708) Centralize xstream initialization

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1708: ----------------------------------- Summary: Centralize xstream initialization Key: DROOLS-1708 URL: https://issues.jboss.org/browse/DROOLS-1708 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Michael Biarnes Kiefer In drools I centralized the creation and initialization of the xstream instance with this commit https://github.com/kiegroup/drools/commit/e3e7c44515949d8fb25978cb2040c50... using the new factory method added here https://github.com/kiegroup/droolsjbpm-knowledge/commit/14438e9ad37ea5fa6... Please extend this enhancement to all other projects using xstream. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9249) undertow provide more statistics

by Ben Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-9249?page=com.atlassian.jira.plugin.... ] Ben Gao commented on WFLY-9249: ------------------------------- I use wildfly 11.0.0.beta。undertow and IO only the values of the current state are provided。 In jboss 7，I can get something like:web reject count, current thread size,the largest thread size. Based on these metrics, I don't need to look at the thread pool size in real time to see if I want to resize the thread pool. But now, without the reject count,the largest thread size,i need real time to see thread pool size > undertow provide more statistics > -------------------------------- > > Key: WFLY-9249 > URL: https://issues.jboss.org/browse/WFLY-9249 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.1.0.Final, 11.0.0.Alpha1, 11.0.0.Beta1 > Environment: all > Reporter: Ben Gao > Assignee: Stuart Douglas > Labels: task > > In now wildfly version,undertow use xnio,in XnioWorker, taskpool is only use jdk ThreadPoolExecutor and not export some statistics. > In connectorStatisticsImpl.java ,only some statistics. > some like:reject count,the largest thread count is very useful statistic,but not export. > Are you going to add these up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9249) undertow provide more statistics

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9249?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-9249: ----------------------------------- I do not understand what the issue is. or what the question is. WildFly 11 comes with much more statistics exposed in undertow and io subsystem. But given you marked WildFly 10 as affected as well, I do not understand if you even tested with WF11 and what exactly are you missing. > undertow provide more statistics > -------------------------------- > > Key: WFLY-9249 > URL: https://issues.jboss.org/browse/WFLY-9249 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.1.0.Final, 11.0.0.Alpha1, 11.0.0.Beta1 > Environment: all > Reporter: Ben Gao > Assignee: Stuart Douglas > Labels: task > > In now wildfly version,undertow use xnio,in XnioWorker, taskpool is only use jdk ThreadPoolExecutor and not export some statistics. > In connectorStatisticsImpl.java ,only some statistics. > some like:reject count,the largest thread count is very useful statistic,but not export. > Are you going to add these up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9249) undertow provide more statistics

by Ben Gao (JIRA)

Ben Gao created WFLY-9249: ----------------------------- Summary: undertow provide more statistics Key: WFLY-9249 URL: https://issues.jboss.org/browse/WFLY-9249 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 11.0.0.Beta1, 11.0.0.Alpha1, 10.1.0.Final Environment: all Reporter: Ben Gao Assignee: Stuart Douglas In now wildfly version,undertow use xnio,in XnioWorker, taskpool is only use jdk ThreadPoolExecutor and not export some statistics. In connectorStatisticsImpl.java ,only some statistics. some like:reject count,the largest thread count is very useful statistic,but not export. Are you going to add these up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9247) Incorrect licenses.xml entry for org.jboss:jboss-ejb-client:jar

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9247?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9247: ----------------------------------- Security: (was: Red Hat Internal) > Incorrect licenses.xml entry for org.jboss:jboss-ejb-client:jar > --------------------------------------------------------------- > > Key: WFLY-9247 > URL: https://issues.jboss.org/browse/WFLY-9247 > Project: WildFly > Issue Type: Bug > Components: Build System, EJB > Reporter: Nikoleta Žiaková > Assignee: Brian Stansberry > Priority: Blocker > > licenses.xml contains: > {code} > <dependency> > <groupId>org.jboss</groupId> > <artifactId>jboss-ejb-client</artifactId> > <version>4.0.0.Beta30-redhat-1</version> > <licenses> > <license> > <name>GNU Lesser General Public License, Version 2.1</name> > <url>http://repository.jboss.org/licenses/lgpl-2.1.txt</url> > </license> > </licenses> > </dependency> > {code} > However, the POM and source files contain {{Apache License, Version 2.0}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9248) Incorrect licenses.xml entry for org.jboss:jboss-ejb-client-legacy

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9248?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9248: ----------------------------------- Security: (was: Red Hat Internal) > Incorrect licenses.xml entry for org.jboss:jboss-ejb-client-legacy > ------------------------------------------------------------------ > > Key: WFLY-9248 > URL: https://issues.jboss.org/browse/WFLY-9248 > Project: WildFly > Issue Type: Bug > Components: Build System, EJB > Reporter: Nikoleta Žiaková > Assignee: Brian Stansberry > > licenses.xml contains: > {code} > <dependency> > <groupId>org.jboss</groupId> > <artifactId>jboss-ejb-client-legacy</artifactId> > <version>3.0.0.Beta7-redhat-1</version> > <licenses> > <license> > <name>Public Domain</name> > <url>http://repository.jboss.org/licenses/cc0-1.0.txt</url> > <distribution>repo</distribution> > </license> > </licenses> > </dependency> > {code} > However, the POM and source files contain {{GNU Lesser General Public License}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9199) Upgrade to http client 1.0.1.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9199?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9199: ---------------------------------------- Changed to 1.0.1.Final as 1.0.0 had some pom mistakes. > Upgrade to http client 1.0.1.Final > ---------------------------------- > > Key: WFLY-9199 > URL: https://issues.jboss.org/browse/WFLY-9199 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Kabir Khan > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9199) Upgrade to http client 1.0.1.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9199?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9199: ----------------------------------- Summary: Upgrade to http client 1.0.1.Final (was: Upgrade to http client 1.0.0.Final) > Upgrade to http client 1.0.1.Final > ---------------------------------- > > Key: WFLY-9199 > URL: https://issues.jboss.org/browse/WFLY-9199 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Kabir Khan > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1354) Potential for deadlock on pool's flush

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1354?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1354: ------------------------------------------------ Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1480095|https://bugzilla.redhat.com/show_bug.cgi?id=1480095] from POST to MODIFIED > Potential for deadlock on pool's flush > -------------------------------------- > > Key: JBJCA-1354 > URL: https://issues.jboss.org/browse/JBJCA-1354 > Project: IronJacamar > Issue Type: Bug > Reporter: Flavia Rainone > Assignee: Flavia Rainone > > There is a potential for deadlock on all flushes in pools. The problem is that flush is synchronized and inside the flush the code can be delegated to listeners, that are external to IronJacamar. > If those listeners use their own synchronization system , they could require synchronization locking in themselves. If there is another thread locking the listener and at some point invoking an operation that results in a pool flush, the system could enter a deadlock state. > An example of stack trace: > {noformat} > Found one Java-level deadlock: > ============================= > "JMSCCThreadPoolWorker-18": > waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool), > which is held by "JMSCCThreadPoolWorker-16" > "JMSCCThreadPoolWorker-16": > waiting to lock monitor 0x00007f1d1c15d138 (object 0x0000000785998598, a com.ibm.mq.connector.outbound.ConnectionEventHandler), > which is held by "JMSCCThreadPoolWorker-17" > "JMSCCThreadPoolWorker-17": > waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool), > which is held by "JMSCCThreadPoolWorker-16" > Java stack information for the threads listed above: > =================================================== > "JMSCCThreadPoolWorker-18": > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322) > - waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool) > at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368) > at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141) > - locked <0x0000000788fe1fa0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848) > at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214) > at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303) > at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241) > "JMSCCThreadPoolWorker-16": > at com.ibm.mq.connector.outbound.ConnectionEventHandler.removeListener(ConnectionEventHandler.java:93) > - waiting to lock <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.removeConnectionEventListener(ManagedConnectionImpl.java:434) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:891) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.flush(SemaphoreArrayListManagedConnectionPool.java:621) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:330) > - locked <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool) > at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368) > at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141) > - locked <0x0000000788fe20b0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848) > at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214) > at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303) > at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241) > "JMSCCThreadPoolWorker-17": > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322) > - waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool) > at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368) > at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141) > - locked <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848) > at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214) > at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229) > at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303) > at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1703. --------------------------------- Resolution: Done Fixed in mvel by https://github.com/mvel/mvel/commit/a63efbdc59f1caa30c4d9cca3dde77139e934f12 > When incompatible varargs constructors exist, resolution sometimes incorrect > ---------------------------------------------------------------------------- > > Key: DROOLS-1703 > URL: https://issues.jboss.org/browse/DROOLS-1703 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: CentOS 7 (x86_64) > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-b12) > OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z) > Reporter: Gerard Krupa > Assignee: Mario Fusco > > We have a class with 3 constructors: > Thingy(String name) > Thingy(String name, Object... args) > Thingy(String name, String version, Object... args) > When calling the constructor with a single paramater from a DRL: > Thingy(drools.getRule().getName()) > we sometimes get an odd exception in our unit tests: > {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [INFO] at java.lang.String.substring(String.java:1927) > [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}} > The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type). > All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. > https://github.com/GJKrupa/DROOLS-1703 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017