November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1317. ------------------------------ Resolution: Rejected > BisocketClientInvoker waits for failed clients > ---------------------------------------------- > > Key: JBREM-1317 > URL: https://issues.jboss.org/browse/JBREM-1317 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: callbacks > Affects Versions: 2.5.4.SP3 > Environment: JBoss EAP 5.1.2 > Reporter: Doug Grove > Assignee: Ron Sigal > Priority: Minor > > When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker: > (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe > The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however. > The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list. > This results in the code waiting for the full duration of the configured timeout. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1316. ------------------------------ Assignee: Ron Sigal Resolution: Done The changes have been committed to https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.x. > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1316. ---------------------------- > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal commented on JBREM-1316: ---------------------------------- The client side parameter "idempotent" has been added. If set to "false", MicroSocketClientInvoker will not retry an invocation, even if "numberOfCallRetries" is greater than 1, once the invocation has been written to the socket. The default value is "true". Unit tests: org.jboss.test.remoting.transport.socket.idempotent.IdempotentTestCase. > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann commented on WFLY-1533: ------------------------------------------ Is any additional info required for this issue? > UT015005: Error invoking method requestDestroyed on listener class > ------------------------------------------------------------------- > > Key: WFLY-1533 > URL: https://issues.jboss.org/browse/WFLY-1533 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4 > Reporter: Juergen Zimmermann > Assignee: Jozef Hartinger > Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip > > > I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace: > 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9 > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2430?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2430: -------------------------------------- Can you please post the full stack track or a reproducer app? > App with custom ContainerResponseFilter (JAX-RS) fails deploy > ------------------------------------------------------------- > > Key: WFLY-2430 > URL: https://issues.jboss.org/browse/WFLY-2430 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7 > Reporter: Rudy De Busscher > Assignee: Stuart Douglas > > Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. > See also https://community.jboss.org/message/844105 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-316) Arbitrary Conflict Resolution can be confusing use LoadOrder

by Mark Proctor (JIRA)

Mark Proctor created DROOLS-316: ----------------------------------- Summary: Arbitrary Conflict Resolution can be confusing use LoadOrder Key: DROOLS-316 URL: https://issues.jboss.org/browse/DROOLS-316 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-316) Arbitrary Conflict Resolution can be confusing use LoadOrder

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-316?page=com.atlassian.jira.plugin... ] Mark Proctor updated DROOLS-316: -------------------------------- Fix Version/s: 6.0.0.Final > Arbitrary Conflict Resolution can be confusing use LoadOrder > ------------------------------------------------------------ > > Key: DROOLS-316 > URL: https://issues.jboss.org/browse/DROOLS-316 > Project: Drools > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1111) Throwable instantiation on TxConnectionListener.TransactionSynchronization

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1111?page=com.atlassian.jira.plugin... ] Luis Barreiro commented on JBJCA-1111: -------------------------------------- Pull Request: https://github.com/ironjacamar/ironjacamar/pull/91 > Throwable instantiation on TxConnectionListener.TransactionSynchronization > -------------------------------------------------------------------------- > > Key: JBJCA-1111 > URL: https://issues.jboss.org/browse/JBJCA-1111 > Project: IronJacamar > Issue Type: Task > Reporter: Luis Barreiro > Assignee: Jesper Pedersen > > In org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.TransactionSynchronization there is a Throwable that is always instantiated during the creation of the object, but in most cases it's never thrown. > There is a performance penalty associated with filling the stack trace of every exception, even if it's not thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1111) Throwable instantiation on TxConnectionListener.TransactionSynchronization

by Luis Barreiro (JIRA)

Luis Barreiro created JBJCA-1111: ------------------------------------ Summary: Throwable instantiation on TxConnectionListener.TransactionSynchronization Key: JBJCA-1111 URL: https://issues.jboss.org/browse/JBJCA-1111 Project: IronJacamar Issue Type: Task Reporter: Luis Barreiro Assignee: Jesper Pedersen In org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.TransactionSynchronization there is a Throwable that is always instantiated during the creation of the object, but in most cases it's never thrown. There is a performance penalty associated with filling the stack trace of every exception, even if it's not thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 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 November 2013