January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Luke Meyers (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Luke Meyers commented on WFLY-4211: ----------------------------------- Forgive me if I'm misunderstanding this project's workflow, but since there's a Git Pull Request that fixes this issue, shouldn't it be in "Pull Request Sent" state rather than "Open"? > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2900) Performance issue with Xalan transformer and very large text nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2900?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2900: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1065128, https://bugzilla.redhat.com/show_bug.cgi?id=1175982, https://bugzilla.redhat.com/show_bug.cgi?id=1181337 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1065128, https://bugzilla.redhat.com/show_bug.cgi?id=1175982) > Performance issue with Xalan transformer and very large text nodes > ------------------------------------------------------------------ > > Key: WFLY-2900 > URL: https://issues.jboss.org/browse/WFLY-2900 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Reporter: Kyle Lape > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.Beta1 > > > It has been observed that when using the {{Transfomer}} to convert a {{StreamSource}} to {{DOMResult}}, the performance of Transform gets worse as the size of the > character data increases. If you have a 50MB text blob in XML, this will take a very long time to finish. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3532: ------------------------------------------- I'll try and explain a little better: When we make an invocation, we start out with an EJBClientInvocationContext representing the invocation client and the invocation parameters. We then choose an EJBReceiver which can handle the invocation and create an EJBReceiverInvocationContext to represent it. The EJBReceiverInvocationContext refers to the EJBReceiver and also Channel used. When we successfully send out an invocation on a channel, we store the fact that we need to wai for a response, and store this fact in a map (ChannelAssociation.waitingMethodInvocations) specifying the invocationId and the EJBReceiverInvocationContext. If the response does not return, or returns with an EJBUnavailableException, we retry the invocation, ultimately using a new EJBReceiverInvocationContext (and so a new Channel). What was causing the exception was that, before retrying, we were not removing the the stored fact that we were waiting on an old EJBReceiverInvocationContext and Channel. When that Channel closed as a result of the server shutting down, it triggered the exception that we were seeing, despite the fact that a new EJBReceiver was being chosen and the retry of the invocation was failing over correctly. > RemoteFailoverTestCase still fails intermittently > -------------------------------------------------- > > Key: WFLY-3532 > URL: https://issues.jboss.org/browse/WFLY-3532 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > Fail rate is at 1.5% atm. > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > (making affected version alpha, but indeed its master) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4244) Naming alias to datasource in deployment

by Frank Denninger (JIRA)

Frank Denninger created WFLY-4244: ------------------------------------- Summary: Naming alias to datasource in deployment Key: WFLY-4244 URL: https://issues.jboss.org/browse/WFLY-4244 Project: WildFly Issue Type: Bug Components: Naming Affects Versions: 8.2.0.Final Reporter: Frank Denninger Assignee: David Lloyd Priority: Minor Using a name alias to a datasource that is defined in the deployment (with a *-ds.xml in the .war) causes a npe when jpa tries to resolve that datasource with the alias. <lookup name="java:/de/datasource/sub" lookup="java:/de/datasource/main"/> When both the datasource and name-alias are defined in the standalone.xml it works as expected. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-3532 at 1/12/15 5:10 PM: -------------------------------------------------------------------- This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way. It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start. In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234 In the case of stop / start, there are a couple of issues: - the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish. Thus, although clean shutdown is in place, in the test case, we are effectively simulating a shutdown in which active invocations get no time to finish - if the shutdown timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results was (Author: rachmato): This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way. It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start. In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234 In the case of stop / start, there are a couple of issues: - the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish - if the timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results > RemoteFailoverTestCase still fails intermittently > -------------------------------------------------- > > Key: WFLY-3532 > URL: https://issues.jboss.org/browse/WFLY-3532 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > Fail rate is at 1.5% atm. > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > (making affected version alpha, but indeed its master) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3532: ------------------------------------------- This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way. It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start. In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234 In the case of stop / start, there are a couple of issues: - the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish - if the timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results > RemoteFailoverTestCase still fails intermittently > -------------------------------------------------- > > Key: WFLY-3532 > URL: https://issues.jboss.org/browse/WFLY-3532 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > Fail rate is at 1.5% atm. > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > (making affected version alpha, but indeed its master) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4243) Appclient resource-def annotations bindings missing in module

by Eduardo Martins (JIRA)

Eduardo Martins created WFLY-4243: ------------------------------------- Summary: Appclient resource-def annotations bindings missing in module Key: WFLY-4243 URL: https://issues.jboss.org/browse/WFLY-4243 Project: WildFly Issue Type: Bug Components: EE Reporter: Eduardo Martins Assignee: Eduardo Martins Resource definitions annotated on app client component classes are missing from module, due such classes are not processed by ModuleJNDIProcessor. The abstract ResourceDefinitionAnnotationProcessor should not add such bindings to class binding configurations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-498) Move logging tests to core

by James Perkins (JIRA)

James Perkins created WFCORE-498: ------------------------------------ Summary: Move logging tests to core Key: WFCORE-498 URL: https://issues.jboss.org/browse/WFCORE-498 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: James Perkins Assignee: James Perkins Priority: Minor Integration logging tests from WildFly should be moved to core where applicable. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4242) Move logging tests to core

by James Perkins (JIRA)

James Perkins created WFLY-4242: ----------------------------------- Summary: Move logging tests to core Key: WFLY-4242 URL: https://issues.jboss.org/browse/WFLY-4242 Project: WildFly Issue Type: Task Components: Test Suite Reporter: James Perkins Assignee: James Perkins Priority: Minor Integration logging tests should be moved to core where applicable. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1905: -------------------------------- OK, got it. So then it is either ResponseFilters and/or destination lists (+/- exclusion lists) in the RequestOptions of the RPC call... > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015