December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-373) clean up lease handling on server side

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-373?page=all ] Tom Elrod updated JBREM-373: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > clean up lease handling on server side > -------------------------------------- > > Key: JBREM-373 > URL: http://jira.jboss.com/jira/browse/JBREM-373 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta1 > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta2 (Boon) > > > In issue JBREM-372, put in a hack for cleaning up lease map within the ServerInvoker where would pass the clientLeases variable from ServerInvoker to the constructor of Lease. Then when LeaseTimerTask fired and event that client was dead, would remove itself from the ServerInvoker's lease map (by client id). > Should not have to pass in the lease map from ServerInvoker. Maybe better approach would be to have ServerInvoker add itself as listener, so when the connection failure event fired, it would be notified and remove the lease from the clientLeases map itself. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-142) better configuration for stream server

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-142?page=all ] Tom Elrod updated JBREM-142: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > better configuration for stream server > -------------------------------------- > > Key: JBREM-142 > URL: http://jira.jboss.com/jira/browse/JBREM-142 > Project: JBoss Remoting > Issue Type: Feature Request > Components: stream > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta2 (Boon) > > > The stream server does have basic configuration for transport, host, and port via system properties (see JBREM-125), but needs better alternative for configuration. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ] Tom Elrod updated JBREM-167: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > RMI Invoker does not use true remoting marshalling/unmarshalling > ---------------------------------------------------------------- > > Key: JBREM-167 > URL: http://jira.jboss.com/jira/browse/JBREM-167 > Project: JBoss Remoting > Issue Type: Bug > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta2 (Boon) > > > In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-344) support for NTLM authentication

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-344?page=all ] Tom Elrod updated JBREM-344: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > support for NTLM authentication > ------------------------------- > > Key: JBREM-344 > URL: http://jira.jboss.com/jira/browse/JBREM-344 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-364) refactor client invoker config for common configurations

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-364?page=all ] Tom Elrod updated JBREM-364: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > refactor client invoker config for common configurations > -------------------------------------------------------- > > Key: JBREM-364 > URL: http://jira.jboss.com/jira/browse/JBREM-364 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > > Currently client invoker implementations all do their own configuration processing. Since many share the same configuration properties, need to standardize these and handle them in the RemoteClientInvoker instead of individual implementations (i.e. SocketClientInvoker, HTTPClientInvoker, etc.). Should follow same model that has been done for ServerInvoker. -- 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

17 years, 10 months

1
0
0 / 0

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

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-433?page=all ] Tom Elrod updated JBREM-433: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > 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.0.0.Beta1 > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > > 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

17 years, 10 months

1
0
0 / 0

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

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-410?page=all ] Tom Elrod updated JBREM-410: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > 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: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > > 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-398) bring AOP Remoting under JBossRemoting project

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-398?page=all ] Tom Elrod updated JBREM-398: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > bring AOP Remoting under JBossRemoting project > ---------------------------------------------- > > Key: JBREM-398 > URL: http://jira.jboss.com/jira/browse/JBREM-398 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > > Need to bring AOP Remoting under the JBossRemoting project for further development and maintenance. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-505) convert jndi to use remoting for transport

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-505?page=all ] Tom Elrod updated JBREM-505: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) > convert jndi to use remoting for transport > ------------------------------------------ > > Key: JBREM-505 > URL: http://jira.jboss.com/jira/browse/JBREM-505 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.2.0.Beta2 (Boon) > > > Need to convert jndi to use remoting as transport. Ties in with JBREM-424. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-315) allow chaining of marshaller/unmarshallers

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-315?page=all ] Tom Elrod updated JBREM-315: ----------------------------- Fix Version/s: 3.0.0.Alpha1 (Otter) (was: 2.2.0.Beta1 (Bluto)) > allow chaining of marshaller/unmarshallers > ------------------------------------------ > > Key: JBREM-315 > URL: http://jira.jboss.com/jira/browse/JBREM-315 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 3.0.0.Alpha1 (Otter) > > > I was thinking of paired marshaller/unmarshaller, which would be > beneficial for more than just this example (compressing payload comes to > mind). Would like to be able to declare a chain of marshallers. For > example: > <marshallers> > <marshaller>org.jboss.remoting.marshall.CompressedMarshaller</marshaller> > <marshaller>org.jboss.remoting.marshall.InvocationMarshaller</marshaller> > <marshaller>org.jboss.remoting.marshall.CountingMarshaller</marshaller> > </marshallers> > <unmarshallers> > <unmarshaller>org.jboss.remoting.marshall.InvocationUnMarshaller</unmarshaller> > <unmarshaller<org.jboss.remoting.marshall.CompressedUnMarshaller</unmarshaller> > of course packaging and order may not be correct in this example. Just > trying to show how would be nice to configure the chain that is used and > that would not require to by symmetrical if didn't want to. > In this example, the CompressedMarshaller would compress the payload, > then write to the InvocationMarshaller, which would write to the > CountingMarshaller, which would then keep track of number of bytes > written and send notifications as was being written. On the server > side, might not need to know number of bytes being read, so would just > have the InvocationUnMarshaller, then CompressedUnMarshaller to > uncompress the payload. -- 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

17 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 December 2006