September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ] Enrique González Martínez resolved WFLY-3724. --------------------------------------------- Resolution: Won't Fix > Batch jobs don't receive partition-specific parameters > ------------------------------------------------------ > > Key: WFLY-3724 > URL: https://issues.jboss.org/browse/WFLY-3724 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Batch > Affects Versions: 8.1.0.Final > Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final > Reporter: Ari Silvan > Assignee: Enrique González Martínez > > When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ] Enrique González Martínez commented on WFLY-3724: ------------------------------------------------- I close the Jira based on the answer of the expert group. > Batch jobs don't receive partition-specific parameters > ------------------------------------------------------ > > Key: WFLY-3724 > URL: https://issues.jboss.org/browse/WFLY-3724 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Batch > Affects Versions: 8.1.0.Final > Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final > Reporter: Ari Silvan > Assignee: Enrique González Martínez > > When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1196) Backport SemaphoreConcurrentLinkedQueueManagedConnectionPool

by John O'Hara (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1196?page=com.atlassian.jira.plugin... ] John O'Hara commented on JBJCA-1196: ------------------------------------ PR created for back port to 1.0: https://github.com/ironjacamar/ironjacamar/pull/226 > Backport SemaphoreConcurrentLinkedQueueManagedConnectionPool > ------------------------------------------------------------ > > Key: JBJCA-1196 > URL: https://issues.jboss.org/browse/JBJCA-1196 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: John O'Hara > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final > > > Can we backport the SemaphoreConcurrentLinkedQueueManagedConnectionPool to 1.0 and 1.1 branches. We will need this to be pulled into EAP6.4 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3652) Network connection leak

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3652. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ] Edson Tirelli closed DROOLS-586. -------------------------------- > Drools doesn't calculate maximum expiration time properly > --------------------------------------------------------- > > Key: DROOLS-586 > URL: https://issues.jboss.org/browse/DROOLS-586 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR2, 6.2.0.Beta1 > Environment: Linux, Java SE 1.7 > Reporter: kairat kushaev > Assignee: Edson Tirelli > Priority: Critical > Fix For: 6.2.0.Beta2 > > > Hello guys, > we found some contradiction between actual Drools behavior, > We use the following Rule: > import drools.test.Event; > dialect "mvel" > declare Event > @role(event) > @expires(10s) > end > rule "ExampleRule" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("bingo!"); > end > In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value. > According to documentation > "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two." > but it is not calculating maximal expiration offset. Also we are using STREAM mode. > Could you please clarify the situation? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ] Edson Tirelli resolved DROOLS-586. ---------------------------------- Fix Version/s: 6.2.0.Beta2 Resolution: Done > Drools doesn't calculate maximum expiration time properly > --------------------------------------------------------- > > Key: DROOLS-586 > URL: https://issues.jboss.org/browse/DROOLS-586 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR2, 6.2.0.Beta1 > Environment: Linux, Java SE 1.7 > Reporter: kairat kushaev > Assignee: Edson Tirelli > Priority: Critical > Fix For: 6.2.0.Beta2 > > > Hello guys, > we found some contradiction between actual Drools behavior, > We use the following Rule: > import drools.test.Event; > dialect "mvel" > declare Event > @role(event) > @expires(10s) > end > rule "ExampleRule" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("bingo!"); > end > In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value. > According to documentation > "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two." > but it is not calculating maximal expiration offset. Also we are using STREAM mode. > Could you please clarify the situation? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ] Edson Tirelli commented on DROOLS-586: -------------------------------------- Sorry for the delay. This behaviour was changed back in Drools 5.1 because of the confusion it was creating and how hard was for users to understand if an event should be in memory or not. The ticket was this: https://issues.jboss.org/browse/JBRULES-2578 After the change, the expiration policy, if it is define, explicitly defines for how long an event will be retained in memory. In case the user prefers the engine to calculate it, then no expiration policy should be set. Unfortunately, as you pointed out, the documentation was not completely updated leading to the confusion. I now updated the documentation accordingly: https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/fafb489e2de286c... Sorry for the confusion. > Drools doesn't calculate maximum expiration time properly > --------------------------------------------------------- > > Key: DROOLS-586 > URL: https://issues.jboss.org/browse/DROOLS-586 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR2, 6.2.0.Beta1 > Environment: Linux, Java SE 1.7 > Reporter: kairat kushaev > Assignee: Edson Tirelli > Priority: Critical > > Hello guys, > we found some contradiction between actual Drools behavior, > We use the following Rule: > import drools.test.Event; > dialect "mvel" > declare Event > @role(event) > @expires(10s) > end > rule "ExampleRule" > when > ( $a : Event(name == "event a") ) and > ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) ) > then > System.out.println("bingo!"); > end > In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value. > According to documentation > "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two." > but it is not calculating maximal expiration offset. Also we are using STREAM mode. > Could you please clarify the situation? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-3) Add the ability to install deployments to a provisioned server

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-3?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFBUILD-3: ------------------------------------ Assignee: Eduardo Martins (was: Stuart Douglas) > Add the ability to install deployments to a provisioned server > -------------------------------------------------------------- > > Key: WFBUILD-3 > URL: https://issues.jboss.org/browse/WFBUILD-3 > Project: WildFly Build Tools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Stuart Douglas > Assignee: Eduardo Martins > > It should be possible to resolve and install (from a maven repository) a user deployment, so a fully functional server can be provisioned directly. The option should be provided to either copy to the deployments directory, or to install it directly in the content repository (so this could work with domain mode as well). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-79) ExplodedDeploymentMarker is not set for sub deployments

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-79?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFCORE-79. ---------------------------------- Fix Version/s: 1.0.0.Alpha6 Resolution: Done > ExplodedDeploymentMarker is not set for sub deployments > ------------------------------------------------------- > > Key: WFCORE-79 > URL: https://issues.jboss.org/browse/WFCORE-79 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 1.0.0.Alpha5 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha6 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-111) ClassLoaderLogContextSelector should optionally include parent CL for context scanning

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-111?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated LOGMGR-111: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1031448 > ClassLoaderLogContextSelector should optionally include parent CL for context scanning > -------------------------------------------------------------------------------------- > > Key: LOGMGR-111 > URL: https://issues.jboss.org/browse/LOGMGR-111 > Project: JBoss Log Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.5.2.Final > Reporter: Dominik Pospisil > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 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 September 2014