|
From: Oliver H. <Ol...@ou...> - 2004-08-16 06:42:46
|
Rod,
This can certainly wait until after 1.1 it's not an urgent requirement. =
But that said the change is quite simple. I'd imagine you'd add a new =
class between RemoteAccessor and UrlBasedRemoteAccessor:
public abstract class RetryingRemoteAccessor=20
extends RemoteAccessor=20
implements MethodInterceptor {
private RetryDecisionManager retryDecisionManager;
public Object invoke(MethodInvocation methodInvocation) throws =
Throwable {
int tries =3D 0;
while(true) {
try {
tries++;
return invokeInternal(methodInvocation);
} catch(RemoteAccessException ex) {
if (retryDecisionManager =3D=3D null=20
|| !retryDecisionManager.shouldRetry(methodInvocation, tries, ex)) =
{
throw ex;
}
}
}
}
protected abstract Object invokeInternal(MethodInvocation =
methodInvocation) throws Throwable;
}
and then all you'd need to do would be to rename the invoke method in =
the *ClientInterceptor classes to invokeInternal.=20
To my mind, the biggest issue with this change it that it introduces the =
possibility that for a singe invocation on the client side a remote =
service may be invoked more than once on the server side. This could =
introduce some very nasty and hard to trace bugs if it's not well =
documented.
J=FCrgen, on a related note. Does it make sense to add a GUID to each =
RemoteInvocation? This would prevent the situation where a proxy server =
may cache the response to a remote invocation (which is probably even =
more nasty that having multiple invocations). Technically POST requests =
should not be cached but in reality they often are. Or should you just =
make sure that the Controller based ServiceExporters are paranoid about =
setting the correct cache control headers? To be honest I don't know if =
this is an issue or not but it does seem like a possibility that should =
be considered.
Ollie
> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
> On Behalf Of Rod Johnson
> Sent: Monday, 16 August 2004 3:50 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] HTTP invoker=20
> remoting strategy
>=20
>=20
> Oliver
>=20
> Thanks for this. Retry is definitely important and the=20
> approach sounds good but I'd probably rather we don't delay=20
> 1.1 final, so long as this can be retrofitted without=20
> breaking anything.
>=20
> I guess a couple of days delay would be OK, but I get nervous=20
> about putting it in at the last minute...
>=20
> R
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf Of Oliver Hutchison
> Sent: 16 August 2004 05:40
> To: spr...@li...
> Subject: RE: [Springframework-developer] HTTP invoker=20
> remoting strategy
>=20
> Andy, J=FCrgen,
>=20
> I've been away for the last week so sorry for the late reply.
>=20
> Attached are some files that add retry support to all the=20
> standard Spring remoting methods. The support is not as=20
> complete as my own remoting implementation but for most cases=20
> should work fine. There's also some code to allow metadata to=20
> be attached to RemoteInvocations (I think this stuff only=20
> works for the RMI and HTTP remoting).=20
>=20
> J=FCrgen would you consider adding this code? The retry support=20
> could integrated higher up the class hierarchy perhaps as a=20
> subclass of RemoteAccessor?
>=20
> Following is an example config.
>=20
> Client:
> <bean id=3D"theManager"=20
> class=3D"org.springframework.remoting.support.RertyingClientProx
> yFactoryBean">
> <property name=3D"wrapedRemoteAccessor"><ref=20
> local=3D"theManagerTarget" /></property>
> <property name=3D"retryDecisionManager"><ref
> local=3D"retryDecisionManager" /></property> =20
> </bean>
>=20
> <bean id=3D"theManagerTarget"=20
> class=3D"org.springframework.remoting.httpinvoker.HttpInvokerCli
> entInterceptor
> ">
> <property=20
> name=3D"serviceInterface"><value>ourcommunity.TheManager</value>
> </property>
> <property=20
> name=3D"serviceUrl"><value>https://${oc.server.addr}/ra/theManag
> er</value></pr
> operty>
> <property name=3D"remoteInvocationFactory"><ref
> local=3D"remoteInvocationFactory" /></property>
> </bean>
> =20
> <bean id=3D"remoteInvocationFactory"=20
> class=3D"ourcommunity.admin.util.remoting.SecurityRemoteInvocati
> onFactory" />
>=20
> <bean id=3D"retryDecisionManager"=20
> class=3D"ourcommunity.admin.util.remoting.OCRetryDecisionManager" />=20
>=20
> Server:
>=20
> <bean id=3D"remoteInvocationExecutor"=20
> class=3D"ourcommunity.util.remoting.SecureRemoteInvocationExecutor" />
> =20
> <bean name=3D"/ra/theManager"=20
> class=3D"org.springframework.remoting.httpinvoker.HttpInvokerSer
> viceExporter">
> <property=20
> name=3D"serviceInterface"><value>ourcommunity.TheManager</value>
> </property>
> <property name=3D"service"><bean=20
> class=3D"ourcommunity.TheManagerImpl"
> /></property> =09
> <property name=3D"remoteInvocationExecutor"><ref
> bean=3D"remoteInvocationExecutor" /></property>
> </bean>
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on=20
> Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic=20
> DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free=20
> Shipping and Free Gift.=20
> http://www.shop4tech.com/z/Inkjet_Cartridges/9> _108_r285
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
|