[JBoss JIRA] Closed: (JBREM-45) Remoting watchdog
by David Lloyd (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-45?page=all ]
David Lloyd closed JBREM-45.
----------------------------
Resolution: Out of Date
Assignee: David Lloyd (was: Tom Elrod)
This issue is in three parts:
1) Build in ability for the server to be aware of clients that exist and their status.
Remoting 3 does not have a notion of client vs. server. That said, an Endpoint will always be aware of the status of its Sessions.
2) Add distributed garbage collection for clients that maintain a remote stub. Will detect that client is no longer available (via watchdog) and will clean up server side references.
This is probably out of scope for Remoting 3 - I'm inclined to let this die until a specific issue arises. Specifically, Remoting 3 doesn't normally utilize the idea of a remote object. Anything that does, will be built on top of Remoting 3 and will probably be responsible for dealing with this functionality.
3) Need ability to disconnect client from server when there has been an extended period of inactivity.
This would be very specific to the protocol. Additionally complicated by the addition of Context/Session layers.
> Remoting watchdog
> -------------------
>
> Key: JBREM-45
> URL: http://jira.jboss.com/jira/browse/JBREM-45
> Project: JBoss Remoting
> Issue Type: Task
> Components: general
> Affects Versions: 1.0.1 beta
> Reporter: Tom Elrod
> Assigned To: David Lloyd
> Fix For: 4.0.0.Beta1
>
>
> Build in ability for the server to be aware of clients that exist and their status. Will be needed for doing distributed garbage collection, client connection timeout, etc.
> Add distributed garbage collection for clients that maintain a remote stub. Will detect that client is no longer available (via watchdog) and will clean up server side references.
> Need ability to disconnect client from server when there has been an extended period of inactivity.
--
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
18 years, 2 months
[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
18 years, 2 months
[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
18 years, 2 months
[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
18 years, 2 months
[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
18 years, 2 months
[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
18 years, 2 months