October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBREM-433) point to multipoint invocation api

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-433?page=comments#action_12379602 ] David Lloyd commented on JBREM-433: ----------------------------------- One possible use that came up in recent meetings: The ability to send a request and verify that all replies match, or to send a request and accept the first reply that meets certain criteria. I still don't know any real-world use cases for this though. > point to multipoint invocation api > ---------------------------------- > > Key: JBREM-433 > URL: http://jira.jboss.com/jira/browse/JBREM-433 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.2.2.GA > Reporter: Tom Elrod > Assigned To: David Lloyd > Fix For: 3.0.0.Alpha1 (Otter) > > > Would like to provide API where client could make single invocation that would be made on multiple remoting servers at one time. The responses for each target server would be aggregated into one response as return to the client call. Basically want to mimic same behavior found within jgroups for this, but provide support over all the transports for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-306) Supports recovery flag

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-306?page=all ] Tim Fox updated JBMESSAGING-306: -------------------------------- Priority: Minor (was: Major) > Supports recovery flag > ---------------------- > > Key: JBMESSAGING-306 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-306 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Minor > Fix For: 2.0.0 Beta 1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Should have flag "supports XA recovery" on persistencemanager. > If = false then only tx id, not all xid fields are persisted on prepare. This should improve performance when xa recovery is not required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-103) Transport progress notification for client

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-103?page=all ] David Lloyd closed JBREM-103. ----------------------------- Resolution: Done Implemented in current Remoting 3 API/Core. > Transport progress notification for client > ------------------------------------------ > > Key: JBREM-103 > URL: http://jira.jboss.com/jira/browse/JBREM-103 > Project: JBoss Remoting > Issue Type: Feature Request > Components: r3 api > Affects Versions: 1.0.2 final > Reporter: Philipp Meier > Assigned To: David Lloyd > Fix For: 3.0.0.Alpha1 (Otter) > > > At the moment there is no way for the client or the server to be notified about the progress of the request / response transmission. Especially for rich clients it would be desireable to be able to register something like a ProgressListener to be notified about the transport progress (push model) or the request the current progress from the remoting implementation (pull model). The discussion in the remoting forum came to the conclusion that this would need some major enhancements of the marshaller. > I set the priority to major because of the major usefulness for richt clients and large dataset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-13) NIO transport

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-13?page=all ] David Lloyd closed JBREM-13. ---------------------------- Fix Version/s: 3.0.0.Alpha1 (Otter) (was: 4.0.0.Beta1) Resolution: Won't Fix Assignee: David Lloyd (was: Tom Elrod) Remoting 3 will use MINA primarily, so NIO and APR are both free. > NIO transport > ------------- > > Key: JBREM-13 > URL: http://jira.jboss.com/jira/browse/JBREM-13 > Project: JBoss Remoting > Issue Type: Feature Request > Components: transport > Affects Versions: 1.0.1 alpha > Reporter: Tom Elrod > Assigned To: David Lloyd > Priority: Optional > Fix For: 3.0.0.Alpha1 (Otter) > > > Add NIO transport. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-103) Transport progress notification for client

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-103?page=all ] David Lloyd updated JBREM-103: ------------------------------ Component/s: r3 api (was: marshall) Assignee: David Lloyd (was: Tom Elrod) > Transport progress notification for client > ------------------------------------------ > > Key: JBREM-103 > URL: http://jira.jboss.com/jira/browse/JBREM-103 > Project: JBoss Remoting > Issue Type: Feature Request > Components: r3 api > Affects Versions: 1.0.2 final > Reporter: Philipp Meier > Assigned To: David Lloyd > Fix For: 3.0.0.Alpha1 (Otter) > > > At the moment there is no way for the client or the server to be notified about the progress of the request / response transmission. Especially for rich clients it would be desireable to be able to register something like a ProgressListener to be notified about the transport progress (push model) or the request the current progress from the remoting implementation (pull model). The discussion in the remoting forum came to the conclusion that this would need some major enhancements of the marshaller. > I set the priority to major because of the major usefulness for richt clients and large dataset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-103) Transport progress notification for client

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-103?page=all ] David Lloyd updated JBREM-103: ------------------------------ Fix Version/s: 3.0.0.Alpha1 (Otter) (was: 4.0.0.Beta1) > Transport progress notification for client > ------------------------------------------ > > Key: JBREM-103 > URL: http://jira.jboss.com/jira/browse/JBREM-103 > Project: JBoss Remoting > Issue Type: Feature Request > Components: r3 api > Affects Versions: 1.0.2 final > Reporter: Philipp Meier > Assigned To: David Lloyd > Fix For: 3.0.0.Alpha1 (Otter) > > > At the moment there is no way for the client or the server to be notified about the progress of the request / response transmission. Especially for rich clients it would be desireable to be able to register something like a ProgressListener to be notified about the transport progress (push model) or the request the current progress from the remoting implementation (pull model). The discussion in the remoting forum came to the conclusion that this would need some major enhancements of the marshaller. > I set the priority to major because of the major usefulness for richt clients and large dataset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-337) EJBException should set cause

by Ortwin Glück (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-337?page=comments#action_12379590 ] Ortwin Glück commented on EJBTHREE-337: --------------------------------------- Seems that this bug is also in another place in EJB-3.0RC8 (sorry can't test this on later versions) when an EJBException caused by a NPE is propagated back through another EJB call as a EJBTransactionRolledbackException: javax.ejb.EJBTransactionRolledbackException: java.lang.NullPointerException at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:93) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:201) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:167) at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:181) at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79) > EJBException should set cause > ----------------------------- > > Key: EJBTHREE-337 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-337 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC3 > Environment: AS-4.0.3SP1, EJB-3.0RC3 > Reporter: Ortwin Glück > Assigned To: William DeCoste > Priority: Trivial > Fix For: EJB 3.0 RC4 - PFD > > > When a NullPointerException is thrown in a session bean method the EJBException only provides the wrapped exception via getCausedByException() and not via the Throwable#getCause() method. That causes stack traces to abort at the EJBException and the real exception is lost. It makes debugging harder. > Caused by: javax.ejb.EJBException: null; CausedByException is: > null > at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:46) > at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:70) > at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:134) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:204) > at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:107) > at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:37) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) > at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:88) > Painful Workaround: > try { > bean.method(); > } catch (EJBException e) { > if (e.getCause() == null) e.initCause(e.getCausedByException()); > throw e; > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-410) look at adding httpc as http client invoker

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-410?page=all ] David Lloyd closed JBREM-410. ----------------------------- Fix Version/s: (was: 3.0.0.Alpha1 (Otter)) Resolution: Won't Fix Assignee: David Lloyd Looks like nhttpc is abandonware at this point. We'll always have MINA if we need this type of HTTP client. > look at adding httpc as http client invoker > ------------------------------------------- > > Key: JBREM-410 > URL: http://jira.jboss.com/jira/browse/JBREM-410 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: transport > Reporter: Tom Elrod > Assigned To: David Lloyd > > https://nhttpc.dev.java.net/ > NIO HTTP Client > An HTTP client built using JDK 1.4 NIO. Scales to thousands of > concurrent client connections per VM with almost no CPU overhead. > BSD license. > In particular, need to see if has NTLM support -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-237) There is No String and Guage monitors in jboss

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-237?page=comments#action_12379584 ] David Lloyd commented on JBREM-237: ----------------------------------- If no update is posted to this issue within a week, I will close it. > There is No String and Guage monitors in jboss > ---------------------------------------------- > > Key: JBREM-237 > URL: http://jira.jboss.com/jira/browse/JBREM-237 > Project: JBoss Remoting > Issue Type: Task > Components: jmx remoting > Reporter: sree roja > Fix For: 3.0.0.Alpha1 (Otter) > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-124) implement APR transport

by David Lloyd (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-124?page=all ] David Lloyd closed JBREM-124. ----------------------------- Resolution: Won't Fix Assignee: David Lloyd This task will not be done directly. Remoting 3 will depend on MINA, which will ultimately get an APR transport layer, so we'll get this for free. > implement APR transport > ----------------------- > > Key: JBREM-124 > URL: http://jira.jboss.com/jira/browse/JBREM-124 > Project: JBoss Remoting > Issue Type: Task > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha1 (Otter) > > > Need to add support of Apache APR based transport. The APR code (from tomcat-connector project) uses native code to manage threads and sockets. The end result is a much better performance using a NIO type approach where only have threads in use for processing data off the socket. When socket is idle, the threads are released and the native code will callback to activate a thread to process the data. > This effort has already been started in JBossRemoting on a branch called apr_transport. Will probably not be fully implemented till after 1.2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007