March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBJCA-1318: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1320720 Bugzilla Update: Perform > list driven ExceptionSorter, StaleConnectionChecker > --------------------------------------------------- > > Key: JBJCA-1318 > URL: https://issues.jboss.org/browse/JBJCA-1318 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Priority: Minor > Fix For: 1.2.8.Final > > > Configuration defined ExceptionSorter, StaleConnectionChecker. > Using an externally (from the implementation) defined "," separated list. > Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files. > ie: > set via <config-property name="FatalExceptions">10099,10100,10101</> > set via <config-property name="StaleExceptions">10099,10100,10101</> > Documentation updated to reflect suggested error codes for vendor based upon the current implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1318: ----------------------------------- Issue Type: Task (was: Enhancement) Fix Version/s: 1.2.8.Final Priority: Minor (was: Major) > list driven ExceptionSorter, StaleConnectionChecker > --------------------------------------------------- > > Key: JBJCA-1318 > URL: https://issues.jboss.org/browse/JBJCA-1318 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Priority: Minor > Fix For: 1.2.8.Final > > > Configuration defined ExceptionSorter, StaleConnectionChecker. > Using an externally (from the implementation) defined "," separated list. > Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files. > ie: > set via <config-property name="FatalExceptions">10099,10100,10101</> > set via <config-property name="StaleExceptions">10099,10100,10101</> > Documentation updated to reflect suggested error codes for vendor based upon the current implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1318. ------------------------------------ Resolution: Done > list driven ExceptionSorter, StaleConnectionChecker > --------------------------------------------------- > > Key: JBJCA-1318 > URL: https://issues.jboss.org/browse/JBJCA-1318 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Priority: Minor > Fix For: 1.2.8.Final > > > Configuration defined ExceptionSorter, StaleConnectionChecker. > Using an externally (from the implementation) defined "," separated list. > Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files. > ie: > set via <config-property name="FatalExceptions">10099,10100,10101</> > set via <config-property name="StaleExceptions">10099,10100,10101</> > Documentation updated to reflect suggested error codes for vendor based upon the current implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-967) Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-967?page=com.atlassian.jira.plugin... ] Petr Široký reassigned DROOLS-967: ---------------------------------- Assignee: Petr Široký (was: Mark Proctor) > Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-967 > URL: https://issues.jboss.org/browse/DROOLS-967 > Project: Drools > Issue Type: Enhancement > Reporter: Michael Reynolds > Assignee: Petr Široký > Priority: Minor > > All of the unit tests in kie-aries-blueprint are ignored with the message to re-enable them once org.apache.aries.blueprint.noosgi 1.0.1 is out. As of right now the latest version of Blueprint noosgi is 1.1.0. > Since the enforcer plugin ensures that all dependencies are managed, we just need to update the managed version and then re-enable the code for adding the namespace handler and unit tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1054) Un-ignore or delete kie-aries-blueprint tests

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1054?page=com.atlassian.jira.plugi... ] Petr Široký closed DROOLS-1054. ------------------------------- Resolution: Duplicate Issue Duplicate of https://issues.jboss.org/browse/DROOLS-967 > Un-ignore or delete kie-aries-blueprint tests > --------------------------------------------- > > Key: DROOLS-1054 > URL: https://issues.jboss.org/browse/DROOLS-1054 > Project: Drools > Issue Type: Task > Components: integration > Affects Versions: 6.4.0.Beta1 > Reporter: Petr Široký > Assignee: Petr Široký > > All the tests under droolsjbpm-integration/kie-are-blueprint are ignored. They need to be reviewed and either enabled or completely removed. Ignored tests are basically useless. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1086) Create KIE EAP installer

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1086?page=com.atlassian.jira.plugi... ] Petr Široký resolved DROOLS-1086. --------------------------------- Fix Version/s: 6.4.0.CR2 Resolution: Done > Create KIE EAP installer > ------------------------ > > Key: DROOLS-1086 > URL: https://issues.jboss.org/browse/DROOLS-1086 > Project: Drools > Issue Type: Bug > Affects Versions: 6.4.0.Beta2 > Reporter: David virgil naranjo > Assignee: Petr Široký > Fix For: 6.4.0.CR2 > > > It is required that an installer for eap is created on KIE side. > Right now the bpms layer is installed by the fuse-bxm-integ eap installer. This installer unzips the kie-eap-distributions-bpms-layer zip and include the bpms layer on the layers file. > Fuse-bxms-integ should be agnostic of fuse and kie version, so the installation of kie on eap should be done independently. > Creating the installer should not be difficult, it would just require to do the same than is done here: > https://github.com/jboss-integration/fuse-bxms-integ/tree/master/release/... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Tomohisa igarashi (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Tomohisa igarashi commented on WFLY-6420: ----------------------------------------- I used latest upstream master of wildfly, the last commit is c5a2e962edef196ec849d4e8e44821aec05dc3e5 > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Tomohisa igarashi (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Tomohisa igarashi reopened WFLY-6420: ------------------------------------- It worked fine without delay also for me at first time, but it did reproduced at second time after restarting WildFly instance. (It looks even worse... \{0,1,1,3,3} were received while \{0,1,2,3,4} were sent) [~jmesnil] could you try it again? {code} 02:12:54,411 INFO [ArtemisHornetQClientTest] [ 13]: Starting to send/receive using HornetQ client API - VMName=24404(a)localhost.localdomain 02:12:54,528 INFO [ArtemisHornetQClientTest] [ 131]: * * * Sent a message 'foobar-0' to 'HornetQQueue[DLQ]' 02:12:54,545 INFO [ArtemisHornetQClientTest] [ 148]: * * * Sent a message 'foobar-1' to 'HornetQQueue[DLQ]' 02:12:54,547 INFO [ArtemisHornetQClientTest] [ 150]: * * * Sent a message 'foobar-2' to 'HornetQQueue[DLQ]' 02:12:54,549 INFO [ArtemisHornetQClientTest] [ 152]: * * * Sent a message 'foobar-3' to 'HornetQQueue[DLQ]' 02:12:54,551 INFO [ArtemisHornetQClientTest] [ 154]: * * * Sent a message 'foobar-4' to 'HornetQQueue[DLQ]' 02:13:24,598 INFO [ArtemisHornetQClientTest] [ 30201]: * * * Received a message 'foobar-0' to 'HornetQQueue[DLQ]' 02:13:24,599 INFO [ArtemisHornetQClientTest] [ 30202]: * * * Received a message 'foobar-1' to 'HornetQQueue[DLQ]' 02:13:24,601 INFO [ArtemisHornetQClientTest] [ 30203]: * * * Received a message 'foobar-1' to 'HornetQQueue[DLQ]' 02:13:24,602 INFO [ArtemisHornetQClientTest] [ 30205]: * * * Received a message 'foobar-3' to 'HornetQQueue[DLQ]' 02:13:24,603 INFO [ArtemisHornetQClientTest] [ 30206]: * * * Received a message 'foobar-3' to 'HornetQQueue[DLQ]' 02:13:24,639 INFO [ArtemisHornetQClientTest] [ 30231]: Finished (HornetQ client) 02:13:25,694 INFO [ArtemisHornetQClientTest] [ 0]: Starting to send/receive using Artemis client API 02:13:25,728 INFO [ArtemisHornetQClientTest] [ 34]: * * * Sent a message 'foobar-0' to 'ActiveMQQueue[DLQ]' 02:13:25,730 INFO [ArtemisHornetQClientTest] [ 36]: * * * Sent a message 'foobar-1' to 'ActiveMQQueue[DLQ]' 02:13:25,731 INFO [ArtemisHornetQClientTest] [ 38]: * * * Sent a message 'foobar-2' to 'ActiveMQQueue[DLQ]' 02:13:25,732 INFO [ArtemisHornetQClientTest] [ 39]: * * * Sent a message 'foobar-3' to 'ActiveMQQueue[DLQ]' 02:13:25,735 INFO [ArtemisHornetQClientTest] [ 42]: * * * Sent a message 'foobar-4' to 'ActiveMQQueue[DLQ]' 02:13:25,758 INFO [ArtemisHornetQClientTest] [ 65]: * * * Received a message 'foobar-0' to 'ActiveMQQueue[DLQ]' 02:13:25,759 INFO [ArtemisHornetQClientTest] [ 66]: * * * Received a message 'foobar-1' to 'ActiveMQQueue[DLQ]' 02:13:25,761 INFO [ArtemisHornetQClientTest] [ 68]: * * * Received a message 'foobar-2' to 'ActiveMQQueue[DLQ]' 02:13:25,762 INFO [ArtemisHornetQClientTest] [ 69]: * * * Received a message 'foobar-3' to 'ActiveMQQueue[DLQ]' 02:13:25,763 INFO [ArtemisHornetQClientTest] [ 70]: * * * Received a message 'foobar-4' to 'ActiveMQQueue[DLQ]' 02:13:25,773 INFO [ArtemisHornetQClientTest] [ 80]: Finished (Artemis client) {code} \\ If I added @Ignore on testHornetQClient(), then it reproduced with testArtemisClient() as well. {code} 02:27:17,216 INFO [ArtemisHornetQClientTest] [ 0]: Starting to send/receive using Artemis client API 02:27:17,293 INFO [ArtemisHornetQClientTest] [ 78]: * * * Sent a message 'foobar-0' to 'ActiveMQQueue[DLQ]' 02:27:17,311 INFO [ArtemisHornetQClientTest] [ 97]: * * * Sent a message 'foobar-1' to 'ActiveMQQueue[DLQ]' 02:27:17,315 INFO [ArtemisHornetQClientTest] [ 101]: * * * Sent a message 'foobar-2' to 'ActiveMQQueue[DLQ]' 02:27:17,319 INFO [ArtemisHornetQClientTest] [ 104]: * * * Sent a message 'foobar-3' to 'ActiveMQQueue[DLQ]' 02:27:17,322 INFO [ArtemisHornetQClientTest] [ 108]: * * * Sent a message 'foobar-4' to 'ActiveMQQueue[DLQ]' 02:27:47,351 INFO [ArtemisHornetQClientTest] [ 30137]: * * * Received a message 'foobar-0' to 'ActiveMQQueue[DLQ]' 02:27:47,352 INFO [ArtemisHornetQClientTest] [ 30138]: * * * Received a message 'foobar-1' to 'ActiveMQQueue[DLQ]' 02:27:47,355 INFO [ArtemisHornetQClientTest] [ 30141]: * * * Received a message 'foobar-2' to 'ActiveMQQueue[DLQ]' 02:27:47,356 INFO [ArtemisHornetQClientTest] [ 30142]: * * * Received a message 'foobar-3' to 'ActiveMQQueue[DLQ]' 02:27:47,358 INFO [ArtemisHornetQClientTest] [ 30143]: * * * Received a message 'foobar-4' to 'ActiveMQQueue[DLQ]' 02:27:47,389 INFO [ArtemisHornetQClientTest] [ 30175]: Finished (Artemis client) {code} > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1450) ResourceBuilderRoot drops data when integrating an externally created child ResourceDefinition

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1450: ---------------------------------------- Summary: ResourceBuilderRoot drops data when integrating an externally created child ResourceDefinition Key: WFCORE-1450 URL: https://issues.jboss.org/browse/WFCORE-1450 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Alpha1 ResourceDefinitionRoot's impl of pushChild(ResourceDefinition child) is doing an incomplete integration of the data from 'child'. It drops everything except attributes, operations and children, losing capabilities and other misc data. I found this will developing tests for WFCORE-1106. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6423) ejb3 subsystem thread-pools default config & xsd misleading

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-6423: ---------------------------------- Summary: ejb3 subsystem thread-pools default config & xsd misleading Key: WFLY-6423 URL: https://issues.jboss.org/browse/WFLY-6423 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.0.0.Final Reporter: Brad Maxwell keepalive-time should be removed from the default profile configurations standalone*.xml / domain.xml as well as the ejb3 docs/schema xsd as the thread pool effectively takes the max-threads count and sets the core size of the thread pool to it, so keepalive-time is never used. Also, max-threads is misleading, the thread count is actually the core size as currently implemented, this causes confusion as if you set max-threads to 300 and you have at most 1 client, your thread pool will create a new thread upon ever request until it reaches 300 and thus while it is technically the max, it is also the core or min, or just # of threads. {code} <thread-pools> <thread-pool name="default"> <max-threads count="10"/> <keepalive-time time="100" unit="milliseconds"/> </thread-pool> </thread-pools> {code} {code} A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no upper bound. When a task is submitted, if the number of running threads is less than the core size, a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be submitted to this type of executor, an out of memory condition may occur. The "name" attribute is the name of the created executor. The "max-threads" attribute must be used to specify the thread pool size. The nested "keepalive-time" element may used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down. The "thread-factory" element specifies the bean name of a specific threads subsystem thread factory to use to create worker threads. Usually it will not be set for an EJB3 thread pool and an appropriate default thread factory will be used. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016