Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-08-25 07:30:12
|
I've actually changed AbstractJndiLocator's internal workings: = Subclasses are supposed to explicitly call a "lookup()" method now, = receiving the freshly located object, rather than getting a = "located(Object)" callback on startup. This is necessary to implement = true hot fetching of the JNDI object (just in time for calling a method = on it, and throwing it away again right afterwards), without temporarily = storing it in an instance variable. =20 In terms of backwards compatibility, it's probably better to keep the = AbstractJndiLocator as-is (deprecating it though) and put the new code = into a JndiObjectLocator base class. Our remoting proxies can then = derive from that new base class, with explicit lookup calls whenever = they need them. =20 There's actually four strategies that we could support out-of-the-box: 1. look up the JNDI object on bean initialization, storing it for later = usage 2. look up the JNDI object on bean initialization (to determine = interfaces or for validation), refetching it for every operation 3. look up the JNDI object on first need (first call to = JndiObjectLocator.lookup), storing it for later usage 4. look up the JNDI object for every operation (every call to = JndiObjectLocator.lookup) =20 Number 1 is current standard behavior. Number 3 requires synchronized = access to the stored JNDI object, but seems to be the appropriate = behavior for EJB lookups (avoiding lazy-init on the bean and all objects = that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during = development; number 2 does the same, but performs early validation, = assuming that the lookup already works on startup. =20 Regarding usage of remote EJB homes: What alternative strategies are = there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do = more efficiently if you accept some assumptions about your server? I = could imagine that on some servers, creating the SLSB instance once and = keeping it for the lifetime of the client application would work: Often, = the SLSB instance is just a proxy that creates new calls to the servers = every time, not allocating any resources on the server... =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Di 24.08.2004 21:01 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I don't think it's a big deal if AbstractJndiLocator doesn't do an immediate lookup on initialization. I actually complained about the fact that it did this a while ago, and this is why most people are recommended to make their EJB proxies lazy, since a lot of the time the JNDI tree is not ready at the time the JNDI lookup is done, if the proxy is not set as ready, depending on the EJB environment. I would be surprised if too many people are using this class, as opposed to JndiObjectFactoryBean... Is this the only thing you want to change in AbstractJndiLocator? As for the question about remote communication on the usage of the home, I don't think there's any guarantees here. A clustering EJB implementation could very well do some remote communication on create calls, if that makes the job of the cluster management code easier. It is typically the bean stub itself that handles cluster failover, so I dont think the home object actually has any real need to do remote communications, but I don't remember there being any contract forbidding it. I'm working from memory, but I do seem to remember that EJB 2.0 does recommend that you now stay in your own VM, when creating a new stub, for efficiency reasons. I.e. load balancing is no longer supposed to be handled by automatically (by default) handing off to EJBs on different cluster members, with that being recommended only for failover. Colin j=FCrgen h=F6ller [werk3AT] wrote: >I've just checked remote proxy caching throughout our remoting = strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, = allowing to perform a fresh lookup if turned off. Analogously, = JndiRmiClientInterceptor should be able to refetch its JNDI object now = if the flag is turned off. > >Our EJB accessors have a similar "cacheHome" flag, which was = implemented a bit crudely: If turned off, it simply overwrote the = instance variable for the home object on every invocation - in a = non-thread-safe manner. Preferably, it should simply fetch a new = temporary proxy on each invocation in that case, just like = RmiClientInterceptor does. > >Unfortunately, this means that our AbstractJndiLocator base class = should change: It should not perform a lookup on initialization in any = case and call located, but rather allow subclasses to explicitly call = lookup when needed (i.e. either on initialization or on each invocation, = depending on the respective flag). > >I've already adapted everything accordingly: All our remote accessors = (which are based on proxies that need lookup, i.e. not the HTTP-based = ones) have consistent support for configurable caching of proxies now. > >The question is: Can we live with the incompatible change in = AbstractJndiLocator class (which is somewhat internal anyway)? Else, I = could introduce a different base class for the above use case. However, = that one would be very similar to the old AbstractJndiLocator, and we = don't really have a need for the old locator class anymore... > >----- > >On a related note: Does a create call on a remote SLSB home usually = involve actual remote communication, or is it rather implemented as = local operation that returns a proxy for an actual SLSB instance? I was = wondering whether our SimpleSlsbInvokerInterceptor actually causes = communication overhead through its create call for each method = invocation... > >Juergen >=20 > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-08-25 08:25:07
|
One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). =20 So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. =20 Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? =20 BTW, hot refetching of JNDI objects also makes sense for local SLSBs, as = requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 25.08.2004 09:33 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I've actually changed AbstractJndiLocator's internal workings: = Subclasses are supposed to explicitly call a "lookup()" method now, = receiving the freshly located object, rather than getting a = "located(Object)" callback on startup. This is necessary to implement = true hot fetching of the JNDI object (just in time for calling a method = on it, and throwing it away again right afterwards), without temporarily = storing it in an instance variable. In terms of backwards compatibility, it's probably better to keep the = AbstractJndiLocator as-is (deprecating it though) and put the new code = into a JndiObjectLocator base class. Our remoting proxies can then = derive from that new base class, with explicit lookup calls whenever = they need them. There's actually four strategies that we could support out-of-the-box: 1. look up the JNDI object on bean initialization, storing it for later = usage 2. look up the JNDI object on bean initialization (to determine = interfaces or for validation), refetching it for every operation 3. look up the JNDI object on first need (first call to = JndiObjectLocator.lookup), storing it for later usage 4. look up the JNDI object for every operation (every call to = JndiObjectLocator.lookup) Number 1 is current standard behavior. Number 3 requires synchronized = access to the stored JNDI object, but seems to be the appropriate = behavior for EJB lookups (avoiding lazy-init on the bean and all objects = that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during = development; number 2 does the same, but performs early validation, = assuming that the lookup already works on startup. Regarding usage of remote EJB homes: What alternative strategies are = there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do = more efficiently if you accept some assumptions about your server? I = could imagine that on some servers, creating the SLSB instance once and = keeping it for the lifetime of the client application would work: Often, = the SLSB instance is just a proxy that creates new calls to the servers = every time, not allocating any resources on the server... Juergen ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Di 24.08.2004 21:01 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I don't think it's a big deal if AbstractJndiLocator doesn't do an immediate lookup on initialization. I actually complained about the fact that it did this a while ago, and this is why most people are recommended to make their EJB proxies lazy, since a lot of the time the JNDI tree is not ready at the time the JNDI lookup is done, if the proxy is not set as ready, depending on the EJB environment. I would be surprised if too many people are using this class, as opposed to JndiObjectFactoryBean... Is this the only thing you want to change in AbstractJndiLocator? As for the question about remote communication on the usage of the home, I don't think there's any guarantees here. A clustering EJB implementation could very well do some remote communication on create calls, if that makes the job of the cluster management code easier. It is typically the bean stub itself that handles cluster failover, so I dont think the home object actually has any real need to do remote communications, but I don't remember there being any contract forbidding it. I'm working from memory, but I do seem to remember that EJB 2.0 does recommend that you now stay in your own VM, when creating a new stub, for efficiency reasons. I.e. load balancing is no longer supposed to be handled by automatically (by default) handing off to EJBs on different cluster members, with that being recommended only for failover. Colin j=FCrgen h=F6ller [werk3AT] wrote: >I've just checked remote proxy caching throughout our remoting = strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, = allowing to perform a fresh lookup if turned off. Analogously, = JndiRmiClientInterceptor should be able to refetch its JNDI object now = if the flag is turned off. > >Our EJB accessors have a similar "cacheHome" flag, which was = implemented a bit crudely: If turned off, it simply overwrote the = instance variable for the home object on every invocation - in a = non-thread-safe manner. Preferably, it should simply fetch a new = temporary proxy on each invocation in that case, just like = RmiClientInterceptor does. > >Unfortunately, this means that our AbstractJndiLocator base class = should change: It should not perform a lookup on initialization in any = case and call located, but rather allow subclasses to explicitly call = lookup when needed (i.e. either on initialization or on each invocation, = depending on the respective flag). > >I've already adapted everything accordingly: All our remote accessors = (which are based on proxies that need lookup, i.e. not the HTTP-based = ones) have consistent support for configurable caching of proxies now. > >The question is: Can we live with the incompatible change in = AbstractJndiLocator class (which is somewhat internal anyway)? Else, I = could introduce a different base class for the above use case. However, = that one would be very similar to the old AbstractJndiLocator, and we = don't really have a need for the old locator class anymore... > >----- > >On a related note: Does a create call on a remote SLSB home usually = involve actual remote communication, or is it rather implemented as = local operation that returns a proxy for an actual SLSB instance? I was = wondering whether our SimpleSlsbInvokerInterceptor actually causes = communication overhead through its create call for each method = invocation... > >Juergen > > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-08-25 13:09:19
|
jürgen höller [werk3AT] wrote: >One further thing: JndiObjectFactoryBean currently returns its located object as-is for the entire lifetime of the client application: If the located object becomes broken at some point of time (which can happen, for example, to an SFSB home or a JMS Destination), clients will carry an unusable reference from then on. Our remoting accessors, on the other hand, expose the same remote service proxy all the time, being able to delegate calls to changing backend stubs (for example, refetched SLSB homes). > >So what we could do is add an analogous "cacheJndiObject" flag to JndiObjectFactoryBean, with the option to turn it off for refetching on every access - while clients still receive a single reference that does not break. In the latter case, we'd have to expose a proxy that implements the same interfaces as the JNDI object, delegating all calls to the current backend object. This could be useful for SFSB homes and JMS Destinations, particularly during development. > >Of course, the choice between looking up once and refetching on every access is a bit simplistic. If we could determine that a reference to a JNDI object or RMI proxy is broken, we could apply a more sophisticated strategy, just refetching if actually necessary. Unfortunately, I don't see a reliable way to achieve this for generic JNDI objects. Is there maybe a specific way for EJB homes, JMS Destinations, RMI proxies, respectively? > > I agree that this is the ideal. When you are working with stateless objects, the best scenario is one where you only do the lookups again when absolutely necessary, i.e. the object is broken. But 'broken' means different things for the different kinds of objects. It may even be application-specific. > >BTW, hot refetching of JNDI objects also makes sense for local SLSBs, as requested by a user some time ago: Local SLSBs can be hot-redeployed too, shutting down the current EJB class loader and starting up a fresh one. So the "cacheHome" flag on our SLSB accessors makes sense for local SLSBs too, particularly during development. Likewise, a "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a local object too, if the server supports hot-redeploying the respective target object. > >Juergen > > |
|
From: <jue...@we...> - 2004-08-25 12:33:59
|
An EJB stub is different from an RMI stub or proxy for HTTP-based = remoting then: The latter can all be shared without issues, being able = to handle multiple calls from different threads in parallel. So we indeed have to call create for each method invocation in = SimpleRemoteSlsbInvokerInterceptor, at least for WebLogic. Any = experiences on whether this is necessary on other EJB servers? I imagine = that some EJB stubs might nicely handle multiple threads, allowing to = cache the stubs... This is probably not worth thinking about for local SLSB invocations. I = just wonder whether there are more efficient strategies that we can = offer for remote SLSB invocations, as alternative to = SimpleRemoteSlsbInvokerInterceptor. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Wednesday, August 25, 2004 2:14 PM To: spr...@li... Subject: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator You can keep around an SLSB stub and use it for multiple calls, but you=20 have to be very careful that all requests do not go through this one=20 stub, as it will potentially become a point of serialization. So this is = really viable only if you also do pooling to handle simultaneous = requests. About 4 years ago, I once had to try to help optimize a WebLogic based=20 app that somebody did, where they decided to be smart, and cached just=20 one SLSB stub in the ServletContext. This stub was used for servicing=20 _all_ requests. Basically WebLogic serialized all requests through the=20 stub. The app could handle less than 5 requests a second. After I=20 suggested going away from the shared stub, along with some small db=20 optimizations, the app was able to handle 75 requests a second... Colin j=FCrgen h=F6ller [werk3AT] wrote: >I've actually changed AbstractJndiLocator's internal workings: = Subclasses are supposed to explicitly call a "lookup()" method now, = receiving the freshly located object, rather than getting a = "located(Object)" callback on startup. This is necessary to implement = true hot fetching of the JNDI object (just in time for calling a method = on it, and throwing it away again right afterwards), without temporarily = storing it in an instance variable. >=20 >In terms of backwards compatibility, it's probably better to keep the = AbstractJndiLocator as-is (deprecating it though) and put the new code = into a JndiObjectLocator base class. Our remoting proxies can then = derive from that new base class, with explicit lookup calls whenever = they need them. >=20 >There's actually four strategies that we could support out-of-the-box: >1. look up the JNDI object on bean initialization, storing it for later = usage >2. look up the JNDI object on bean initialization (to determine = interfaces or for validation), refetching it for every operation >3. look up the JNDI object on first need (first call to = JndiObjectLocator.lookup), storing it for later usage >4. look up the JNDI object for every operation (every call to = JndiObjectLocator.lookup) >=20 >Number 1 is current standard behavior. Number 3 requires synchronized = access to the stored JNDI object, but seems to be the appropriate = behavior for EJB lookups (avoiding lazy-init on the bean and all objects = that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during = development; number 2 does the same, but performs early validation, = assuming that the lookup already works on startup. >=20 >Regarding usage of remote EJB homes: What alternative strategies are = there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do = more efficiently if you accept some assumptions about your server? I = could imagine that on some servers, creating the SLSB instance once and = keeping it for the lifetime of the client application would work: Often, = the SLSB instance is just a proxy that creates new calls to the servers = every time, not allocating any resources on the server... >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Di 24.08.2004 21:01 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I don't think it's a big deal if AbstractJndiLocator doesn't do an >immediate lookup on initialization. I actually complained about the = fact >that it did this a while ago, and this is why most people are >recommended to make their EJB proxies lazy, since a lot of the time the >JNDI tree is not ready at the time the JNDI lookup is done, if the = proxy >is not set as ready, depending on the EJB environment. I would be >surprised if too many people are using this class, as opposed to >JndiObjectFactoryBean... Is this the only thing you want to change in >AbstractJndiLocator? > >As for the question about remote communication on the usage of the = home, >I don't think there's any guarantees here. A clustering EJB >implementation could very well do some remote communication on create >calls, if that makes the job of the cluster management code easier. It >is typically the bean stub itself that handles cluster failover, so I >dont think the home object actually has any real need to do remote >communications, but I don't remember there being any contract = forbidding >it. I'm working from memory, but I do seem to remember that EJB 2.0 = does >recommend that you now stay in your own VM, when creating a new stub, >for efficiency reasons. I.e. load balancing is no longer supposed to be >handled by automatically (by default) handing off to EJBs on different >cluster members, with that being recommended only for failover. > >Colin > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>I've just checked remote proxy caching throughout our remoting = strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, = allowing to perform a fresh lookup if turned off. Analogously, = JndiRmiClientInterceptor should be able to refetch its JNDI object now = if the flag is turned off. >> >>Our EJB accessors have a similar "cacheHome" flag, which was = implemented a bit crudely: If turned off, it simply overwrote the = instance variable for the home object on every invocation - in a = non-thread-safe manner. Preferably, it should simply fetch a new = temporary proxy on each invocation in that case, just like = RmiClientInterceptor does. >> >>Unfortunately, this means that our AbstractJndiLocator base class = should change: It should not perform a lookup on initialization in any = case and call located, but rather allow subclasses to explicitly call = lookup when needed (i.e. either on initialization or on each invocation, = depending on the respective flag). >> >>I've already adapted everything accordingly: All our remote accessors = (which are based on proxies that need lookup, i.e. not the HTTP-based = ones) have consistent support for configurable caching of proxies now. >> >>The question is: Can we live with the incompatible change in = AbstractJndiLocator class (which is somewhat internal anyway)? Else, I = could introduce a different base class for the above use case. However, = that one would be very similar to the old AbstractJndiLocator, and we = don't really have a need for the old locator class anymore... >> >>----- >> >>On a related note: Does a create call on a remote SLSB home usually = involve actual remote communication, or is it rather implemented as = local operation that returns a proxy for an actual SLSB instance? I was = wondering whether our SimpleSlsbInvokerInterceptor actually causes = communication overhead through its create call for each method = invocation... >> >>Juergen >> =20 >> ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-08-25 19:20:44
|
I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). =20 I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. =20 While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. =20 I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 25.08.2004 15:08 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator j=FCrgen h=F6ller [werk3AT] wrote: >One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). > >So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. > >Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? >=20 > I agree that this is the ideal. When you are working with stateless objects, the best scenario is one where you only do the lookups again when absolutely necessary, i.e. the object is broken. But 'broken' means different things for the different kinds of objects. It may even be application-specific. > >BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. > >Juergen > > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-08-29 14:23:50
|
Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. =20 * AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option = (alongside the existing "cacheHome"): Turn it off to get lazy fetching = of the EJB home, on first access, caching the home from then on. The = interceptor respectively proxy bean can still be initialized eagerly, so = there's no need to mark its bean definition as "lazy-init". =20 * AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. =20 * RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. =20 So there are two main new features for EJB and RMI: lazy initialization = of a cached EJB home without resorting to defining the bean as = "lazy-init", and refreshing the EJB home object respectively RMI proxy = if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. =20 This brings the EJB and RMI support to the same convenience level as the = HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up the = remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 25.08.2004 21:23 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. Juergen ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 25.08.2004 15:08 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator j=FCrgen h=F6ller [werk3AT] wrote: >One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). > >So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. > >Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? > > I agree that this is the ideal. When you are working with stateless objects, the best scenario is one where you only do the lookups again when absolutely necessary, i.e. the object is broken. But 'broken' means different things for the different kinds of objects. It may even be application-specific. > >BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. > >Juergen > > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-08-29 14:48:14
|
Forget to mention that I've also refactored = AbstractRemoteSlsbInvokerInterceptor and = SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching = strategies (as opposed to home fetching strategies) should be = straightforward now. =20 For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed with = "getSessionBeanInstance" and "releaseSessionBeanInstance" getting = overridden to work on a shared SLSB proxy instance, rather than creating = one for each invocation. The SLSB proxy could be created in an = "afterPropertiesSet" implementation (calling "newSessionBeanInstance") = and removed in a "destroy" implementation (calling = "removeSessionBeanInstance"). =20 In total, all defaults should behave just like before, but I believe = that the new EJB access options (particularly lazy lookup and refresh on = connect failure) provide significant value for typical usage scenarios. = And the new RMI options increase the value of standalone RMI as remoting = strategy, making them a more credible alternative to HTTP-based = remoting. =20 Colin, what's your view on these changes? We should discuss any issues = ASAP, to be able to release 1.1 final by the end of the coming week. It = would also be great to discuss those options briefly in the reference = manual - do you maybe have the chance to add some brief paragraphs on = them? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: So 29.08.2004 16:27 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. * AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option = (alongside the existing "cacheHome"): Turn it off to get lazy fetching = of the EJB home, on first access, caching the home from then on. The = interceptor respectively proxy bean can still be initialized eagerly, so = there's no need to mark its bean definition as "lazy-init". * AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. * RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. So there are two main new features for EJB and RMI: lazy initialization = of a cached EJB home without resorting to defining the bean as = "lazy-init", and refreshing the EJB home object respectively RMI proxy = if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. This brings the EJB and RMI support to the same convenience level as the = HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up the = remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 25.08.2004 21:23 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. Juergen ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 25.08.2004 15:08 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator j=FCrgen h=F6ller [werk3AT] wrote: >One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). > >So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. > >Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? > > I agree that this is the ideal. When you are working with stateless objects, the best scenario is one where you only do the lookups again when absolutely necessary, i.e. the object is broken. But 'broken' means different things for the different kinds of objects. It may even be application-specific. > >BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. > >Juergen > > ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-08-29 15:21:53
|
I think the enhancements are going to help people. From reading your mail below (haven't looked at the code yet), it sounds like the lookupHomeOnStartup option is on by default. I know that this makes the code completely backwards compatible, but IMHO it probably makes more sense to have it default to off. In a lot fo containers you had to use the lazy-init=true setting on the bean previously so you wouldn't access the ejbs before they were actually loaded, so I think most users will want this on by default. Of course, there are some people who will get an error message (on bad setup) later rather than sooner with this setup, but I think it's going to be less people than get burned by the fact their EJBs are not loaded yet. I'll update the ejbtest integration test/sample at a minimum to test some of the new options. I should be able to update the ejb docs to mention the new options. jürgen höller [werk3AT] wrote: >Forget to mention that I've also refactored AbstractRemoteSlsbInvokerInterceptor and SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching strategies (as opposed to home fetching strategies) should be straightforward now. > >For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting overridden to work on a shared SLSB proxy instance, rather than creating one for each invocation. The SLSB proxy could be created in an "afterPropertiesSet" implementation (calling "newSessionBeanInstance") and removed in a "destroy" implementation (calling "removeSessionBeanInstance"). > >In total, all defaults should behave just like before, but I believe that the new EJB access options (particularly lazy lookup and refresh on connect failure) provide significant value for typical usage scenarios. And the new RMI options increase the value of standalone RMI as remoting strategy, making them a more credible alternative to HTTP-based remoting. > >Colin, what's your view on these changes? We should discuss any issues ASAP, to be able to release 1.1 final by the end of the coming week. It would also be great to discuss those options briefly in the reference manual - do you maybe have the chance to add some brief paragraphs on them? > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >Gesendet: So 29.08.2004 16:27 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator > > > >Everything's committed since Friday. Everybody who has the chance, please give the new options a try, in particular the new EJB access options. I've tested the RMI options quite a bit, but not had a chance to play with the EJB options yet. > >* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option (alongside the existing "cacheHome"): Turn it off to get lazy fetching of the EJB home, on first access, caching the home from then on. The interceptor respectively proxy bean can still be initialized eagerly, so there's no need to mark its bean definition as "lazy-init". > >* AbstractRemoteSlsbInvokerInterceptor has a new "refreshHomeOnConnectFailure" option: Turn it on to automatically refresh the home and retry if a call resulted in a java.rmi.ConnectException. This should work without side effects, as ConnectException should just be thrown if no socket connection to the target server could be established: Retrying the call with a fresh EJB home should be a safe operation in that case. The default is off, though. > >* RmiClientInterceptor and JndiRmiClientInterceptor have analogous "lookupRmiProxyOnStartup", "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" options. By default, the first two options are on and the latter is off. Those can in principle be combined in any way, as they are independent to a large degree. The refresh option behaves similarly to with EJB homes: It refreshes and retries on java.rmi.ConnectException. > >So there are two main new features for EJB and RMI: lazy initialization of a cached EJB home without resorting to defining the bean as "lazy-init", and refreshing the EJB home object respectively RMI proxy if it became stale. The latter allows for hot restarts of the EJB respectively RMI server without restarting the client, no matter whether the EJB home supports auto-failover itself. > >This brings the EJB and RMI support to the same convenience level as the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up the remote server later than the client or restarting the remote server without restarting the client does not pose a problem for HTTP-based remoting in the first place, as there is no proxy holding a connection that could become stale there. Therefore, the above options are not necessary for the HTTP remoting support in the first place. > >Juergen > > > >________________________________ > >Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >Gesendet: Mi 25.08.2004 21:23 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator > > > >I've basically finished the reworked proxy fetching stuff: RmiClientInterceptor, JndiRmiClientInterceptor and AbstractSlsbInvokerInterceptor all support the four fetching strategies I've mentioned, through two flags (look proxy up on startup, cache proxy). As those accessors are capable of refetching the proxy now, we can also easily allow for further strategies, for example to check a proxy and refetch if it is broken (with custom check implementation). > >I've also added a JndiObjectTargetSource that can be used to refetch a JNDI object for each call. It supports two analogous flags, so the actual fetching strategy can be customized. I've tested this with an OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each createConnection call can trigger a fresh JNDI lookup to make sure that the ConnectionFactory reference is valid. > >While refetching of RMI proxies and JNDI objects for each operation of course represents a significant overhead, it's not too bad if the respective objects are rarely used. I still rather consider this as development feature, though, to allow restarting of remote processes while keeping the clients alive. Lazily initializing the references is a good feature for production too: The remote processes do not have to be alive when the clients start up then. > >I'll commit all of that stuff tomorrow, after having gone through it in terms of documentation etc. I'll also put some further thought into custom refetching strategies, providing appropriate hooks for subclasses. In the future, we might introduce an appropriate strategy interface for that. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Mi 25.08.2004 15:08 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator > > > >jürgen höller [werk3AT] wrote: > > > >>One further thing: JndiObjectFactoryBean currently returns its located object as-is for the entire lifetime of the client application: If the located object becomes broken at some point of time (which can happen, for example, to an SFSB home or a JMS Destination), clients will carry an unusable reference from then on. Our remoting accessors, on the other hand, expose the same remote service proxy all the time, being able to delegate calls to changing backend stubs (for example, refetched SLSB homes). >> >>So what we could do is add an analogous "cacheJndiObject" flag to JndiObjectFactoryBean, with the option to turn it off for refetching on every access - while clients still receive a single reference that does not break. In the latter case, we'd have to expose a proxy that implements the same interfaces as the JNDI object, delegating all calls to the current backend object. This could be useful for SFSB homes and JMS Destinations, particularly during development. >> >>Of course, the choice between looking up once and refetching on every access is a bit simplistic. If we could determine that a reference to a JNDI object or RMI proxy is broken, we could apply a more sophisticated strategy, just refetching if actually necessary. Unfortunately, I don't see a reliable way to achieve this for generic JNDI objects. Is there maybe a specific way for EJB homes, JMS Destinations, RMI proxies, respectively? >> >> >> >> >I agree that this is the ideal. When you are working with stateless >objects, the best scenario is one where you only do the lookups again >when absolutely necessary, i.e. the object is broken. But 'broken' means >different things for the different kinds of objects. It may even be >application-specific. > > > >>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, as requested by a user some time ago: Local SLSBs can be hot-redeployed too, shutting down the current EJB class loader and starting up a fresh one. So the "cacheHome" flag on our SLSB accessors makes sense for local SLSBs too, particularly during development. Likewise, a "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a local object too, if the server supports hot-redeploying the respective target object. >> >>Juergen >> >> |
|
From: <jue...@we...> - 2004-08-30 13:52:42
|
I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. = Its only disadvantage, aside from backwards compatibility, is that it = requires a synchronized block for accessing the home object, which could = have negative effects in a highly concurrent environment. The current implementation tries to avoid synchronization wherever it = can: In particular, "lookupHomeOnStartup"=3Dtrue does not use = synchronization unless you also specified "refreshHomeOnConnectFailure". = Same goes for RmiClientInterceptor and JndiRmiClientInterceptor. That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse = and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for = both lazy home lookup and automatic refresh/retry if the home became = stale (for example, after a restart of the target server). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Sunday, August 29, 2004 5:21 PM To: spr...@li... Subject: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator I think the enhancements are going to help people. From reading your=20 mail below (haven't looked at the code yet), it sounds like the=20 lookupHomeOnStartup option is on by default. I know that this makes the=20 code completely backwards compatible, but IMHO it probably makes more=20 sense to have it default to off. In a lot fo containers you had to use=20 the lazy-init=3Dtrue setting on the bean previously so you wouldn't = access=20 the ejbs before they were actually loaded, so I think most users will=20 want this on by default. Of course, there are some people who will get=20 an error message (on bad setup) later rather than sooner with this=20 setup, but I think it's going to be less people than get burned by the=20 fact their EJBs are not loaded yet. I'll update the ejbtest integration test/sample at a minimum to test=20 some of the new options. I should be able to update the ejb docs to=20 mention the new options. j=FCrgen h=F6ller [werk3AT] wrote: >Forget to mention that I've also refactored = AbstractRemoteSlsbInvokerInterceptor and = SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching = strategies (as opposed to home fetching strategies) should be = straightforward now. >=20 >For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed = with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting = overridden to work on a shared SLSB proxy instance, rather than creating = one for each invocation. The SLSB proxy could be created in an = "afterPropertiesSet" implementation (calling "newSessionBeanInstance") = and removed in a "destroy" implementation (calling = "removeSessionBeanInstance"). >=20 >In total, all defaults should behave just like before, but I believe = that the new EJB access options (particularly lazy lookup and refresh on = connect failure) provide significant value for typical usage scenarios. = And the new RMI options increase the value of standalone RMI as remoting = strategy, making them a more credible alternative to HTTP-based = remoting. >=20 >Colin, what's your view on these changes? We should discuss any issues = ASAP, to be able to release 1.1 final by the end of the coming week. It = would also be great to discuss those options briefly in the reference = manual - do you maybe have the chance to add some brief paragraphs on = them? >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: So 29.08.2004 16:27 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. > >* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option = (alongside the existing "cacheHome"): Turn it off to get lazy fetching = of the EJB home, on first access, caching the home from then on. The = interceptor respectively proxy bean can still be initialized eagerly, so = there's no need to mark its bean definition as "lazy-init". > >* AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. > >* RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. > >So there are two main new features for EJB and RMI: lazy initialization = of a cached EJB home without resorting to defining the bean as = "lazy-init", and refreshing the EJB home object respectively RMI proxy = if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. > >This brings the EJB and RMI support to the same convenience level as = the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up = the remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. > >Juergen > > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: Mi 25.08.2004 21:23 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). > >I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. > >While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. > >I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Mi 25.08.2004 15:08 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). >> >>So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. >> >>Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? >> >> >> =20 >> >I agree that this is the ideal. When you are working with stateless >objects, the best scenario is one where you only do the lookups again >when absolutely necessary, i.e. the object is broken. But 'broken' = means >different things for the different kinds of objects. It may even be >application-specific. > > =20 > >>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. >> >>Juergen >> =20 >> ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-08-31 23:09:20
|
How do we proceed with the defaults? Should we make = "lookupHomeOnStartup"=3Dfalse and "refreshHomeOnConnectFailure"=3Dtrue = the default? =20 FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", = "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to = "lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", = respectively. The RMI docs consistently call that thing "stub", so I = thought we should too, as it also avoids confustion with an AOP proxy as = provided by RmiProxyFactoryBean. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Mo 30.08.2004 15:56 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. = Its only disadvantage, aside from backwards compatibility, is that it = requires a synchronized block for accessing the home object, which could = have negative effects in a highly concurrent environment. The current implementation tries to avoid synchronization wherever it = can: In particular, "lookupHomeOnStartup"=3Dtrue does not use = synchronization unless you also specified "refreshHomeOnConnectFailure". = Same goes for RmiClientInterceptor and JndiRmiClientInterceptor. That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse = and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for = both lazy home lookup and automatic refresh/retry if the home became = stale (for example, after a restart of the target server). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Sunday, August 29, 2004 5:21 PM To: spr...@li... Subject: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator I think the enhancements are going to help people. From reading your mail below (haven't looked at the code yet), it sounds like the lookupHomeOnStartup option is on by default. I know that this makes the code completely backwards compatible, but IMHO it probably makes more sense to have it default to off. In a lot fo containers you had to use the lazy-init=3Dtrue setting on the bean previously so you wouldn't = access the ejbs before they were actually loaded, so I think most users will want this on by default. Of course, there are some people who will get an error message (on bad setup) later rather than sooner with this setup, but I think it's going to be less people than get burned by the fact their EJBs are not loaded yet. I'll update the ejbtest integration test/sample at a minimum to test some of the new options. I should be able to update the ejb docs to mention the new options. j=FCrgen h=F6ller [werk3AT] wrote: >Forget to mention that I've also refactored = AbstractRemoteSlsbInvokerInterceptor and = SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching = strategies (as opposed to home fetching strategies) should be = straightforward now. > >For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed = with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting = overridden to work on a shared SLSB proxy instance, rather than creating = one for each invocation. The SLSB proxy could be created in an = "afterPropertiesSet" implementation (calling "newSessionBeanInstance") = and removed in a "destroy" implementation (calling = "removeSessionBeanInstance"). > >In total, all defaults should behave just like before, but I believe = that the new EJB access options (particularly lazy lookup and refresh on = connect failure) provide significant value for typical usage scenarios. = And the new RMI options increase the value of standalone RMI as remoting = strategy, making them a more credible alternative to HTTP-based = remoting. > >Colin, what's your view on these changes? We should discuss any issues = ASAP, to be able to release 1.1 final by the end of the coming week. It = would also be great to discuss those options briefly in the reference = manual - do you maybe have the chance to add some brief paragraphs on = them? > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: So 29.08.2004 16:27 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. > >* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option = (alongside the existing "cacheHome"): Turn it off to get lazy fetching = of the EJB home, on first access, caching the home from then on. The = interceptor respectively proxy bean can still be initialized eagerly, so = there's no need to mark its bean definition as "lazy-init". > >* AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. > >* RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. > >So there are two main new features for EJB and RMI: lazy initialization = of a cached EJB home without resorting to defining the bean as = "lazy-init", and refreshing the EJB home object respectively RMI proxy = if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. > >This brings the EJB and RMI support to the same convenience level as = the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up = the remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. > >Juergen > > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: Mi 25.08.2004 21:23 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). > >I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. > >While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. > >I'll commit all of that stuff tomorrow, after having gone through it in = terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Mi 25.08.2004 15:08 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >j=FCrgen h=F6ller [werk3AT] wrote: > >=20 > >>One further thing: JndiObjectFactoryBean currently returns its located = object as-is for the entire lifetime of the client application: If the = located object becomes broken at some point of time (which can happen, = for example, to an SFSB home or a JMS Destination), clients will carry = an unusable reference from then on. Our remoting accessors, on the other = hand, expose the same remote service proxy all the time, being able to = delegate calls to changing backend stubs (for example, refetched SLSB = homes). >> >>So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. >> >>Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? >> >> >> =20 >> >I agree that this is the ideal. When you are working with stateless >objects, the best scenario is one where you only do the lookups again >when absolutely necessary, i.e. the object is broken. But 'broken' = means >different things for the different kinds of objects. It may even be >application-specific. > >=20 > >>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. >> >>Juergen >> =20 >> ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-09-01 03:44:22
|
I agree that the renaming makes sense. I would go for sure with "lookupHomeOnStartup"=false as a default. As for "refreshHomeOnConnectFailure"=true, I can't really think of any negative consequences. Code all looks ok to me, I'll give it a runthrough tomorrow. jürgen höller [werk3AT] wrote: >How do we proceed with the defaults? Should we make "lookupHomeOnStartup"=false and "refreshHomeOnConnectFailure"=true the default? > >FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to "lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", respectively. The RMI docs consistently call that thing "stub", so I thought we should too, as it also avoids confustion with an AOP proxy as provided by RmiProxyFactoryBean. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >Gesendet: Mo 30.08.2004 15:56 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator > > > >I agree that "lookupHomeOnStartup"=false would be a sensible default. Its only disadvantage, aside from backwards compatibility, is that it requires a synchronized block for accessing the home object, which could have negative effects in a highly concurrent environment. > >The current implementation tries to avoid synchronization wherever it can: In particular, "lookupHomeOnStartup"=true does not use synchronization unless you also specified "refreshHomeOnConnectFailure". Same goes for RmiClientInterceptor and JndiRmiClientInterceptor. > >That said, I still recommend to specify "lookupHomeOnStartup"=false and "refreshHomeOnConnectFailure"=true in the usual case, to allow for both lazy home lookup and automatic refresh/retry if the home became stale (for example, after a restart of the target server). > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Sunday, August 29, 2004 5:21 PM >To: spr...@li... >Subject: Re: [Springframework-developer] JNDI object caching and >AbstractJndiLocator > > >I think the enhancements are going to help people. From reading your >mail below (haven't looked at the code yet), it sounds like the >lookupHomeOnStartup option is on by default. I know that this makes the >code completely backwards compatible, but IMHO it probably makes more >sense to have it default to off. In a lot fo containers you had to use >the lazy-init=true setting on the bean previously so you wouldn't access >the ejbs before they were actually loaded, so I think most users will >want this on by default. Of course, there are some people who will get >an error message (on bad setup) later rather than sooner with this >setup, but I think it's going to be less people than get burned by the >fact their EJBs are not loaded yet. > >I'll update the ejbtest integration test/sample at a minimum to test >some of the new options. I should be able to update the ejb docs to >mention the new options. > > >jürgen höller [werk3AT] wrote: > > > >>Forget to mention that I've also refactored AbstractRemoteSlsbInvokerInterceptor and SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching strategies (as opposed to home fetching strategies) should be straightforward now. >> >>For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting overridden to work on a shared SLSB proxy instance, rather than creating one for each invocation. The SLSB proxy could be created in an "afterPropertiesSet" implementation (calling "newSessionBeanInstance") and removed in a "destroy" implementation (calling "removeSessionBeanInstance"). >> >>In total, all defaults should behave just like before, but I believe that the new EJB access options (particularly lazy lookup and refresh on connect failure) provide significant value for typical usage scenarios. And the new RMI options increase the value of standalone RMI as remoting strategy, making them a more credible alternative to HTTP-based remoting. >> >>Colin, what's your view on these changes? We should discuss any issues ASAP, to be able to release 1.1 final by the end of the coming week. It would also be great to discuss those options briefly in the reference manual - do you maybe have the chance to add some brief paragraphs on them? >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >>Gesendet: So 29.08.2004 16:27 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator >> >> >> >>Everything's committed since Friday. Everybody who has the chance, please give the new options a try, in particular the new EJB access options. I've tested the RMI options quite a bit, but not had a chance to play with the EJB options yet. >> >>* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option (alongside the existing "cacheHome"): Turn it off to get lazy fetching of the EJB home, on first access, caching the home from then on. The interceptor respectively proxy bean can still be initialized eagerly, so there's no need to mark its bean definition as "lazy-init". >> >>* AbstractRemoteSlsbInvokerInterceptor has a new "refreshHomeOnConnectFailure" option: Turn it on to automatically refresh the home and retry if a call resulted in a java.rmi.ConnectException. This should work without side effects, as ConnectException should just be thrown if no socket connection to the target server could be established: Retrying the call with a fresh EJB home should be a safe operation in that case. The default is off, though. >> >>* RmiClientInterceptor and JndiRmiClientInterceptor have analogous "lookupRmiProxyOnStartup", "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" options. By default, the first two options are on and the latter is off. Those can in principle be combined in any way, as they are independent to a large degree. The refresh option behaves similarly to with EJB homes: It refreshes and retries on java.rmi.ConnectException. >> >>So there are two main new features for EJB and RMI: lazy initialization of a cached EJB home without resorting to defining the bean as "lazy-init", and refreshing the EJB home object respectively RMI proxy if it became stale. The latter allows for hot restarts of the EJB respectively RMI server without restarting the client, no matter whether the EJB home supports auto-failover itself. >> >>This brings the EJB and RMI support to the same convenience level as the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up the remote server later than the client or restarting the remote server without restarting the client does not pose a problem for HTTP-based remoting in the first place, as there is no proxy holding a connection that could become stale there. Therefore, the above options are not necessary for the HTTP remoting support in the first place. >> >>Juergen >> >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >>Gesendet: Mi 25.08.2004 21:23 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator >> >> >> >>I've basically finished the reworked proxy fetching stuff: RmiClientInterceptor, JndiRmiClientInterceptor and AbstractSlsbInvokerInterceptor all support the four fetching strategies I've mentioned, through two flags (look proxy up on startup, cache proxy). As those accessors are capable of refetching the proxy now, we can also easily allow for further strategies, for example to check a proxy and refetch if it is broken (with custom check implementation). >> >>I've also added a JndiObjectTargetSource that can be used to refetch a JNDI object for each call. It supports two analogous flags, so the actual fetching strategy can be customized. I've tested this with an OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each createConnection call can trigger a fresh JNDI lookup to make sure that the ConnectionFactory reference is valid. >> >>While refetching of RMI proxies and JNDI objects for each operation of course represents a significant overhead, it's not too bad if the respective objects are rarely used. I still rather consider this as development feature, though, to allow restarting of remote processes while keeping the clients alive. Lazily initializing the references is a good feature for production too: The remote processes do not have to be alive when the clients start up then. >> >>I'll commit all of that stuff tomorrow, after having gone through it in terms of documentation etc. I'll also put some further thought into custom refetching strategies, providing appropriate hooks for subclasses. In the future, we might introduce an appropriate strategy interface for that. >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag von Colin Sampaleanu >>Gesendet: Mi 25.08.2004 15:08 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator >> >> >> >>jürgen höller [werk3AT] wrote: >> >> >> >> >> >>>One further thing: JndiObjectFactoryBean currently returns its located object as-is for the entire lifetime of the client application: If the located object becomes broken at some point of time (which can happen, for example, to an SFSB home or a JMS Destination), clients will carry an unusable reference from then on. Our remoting accessors, on the other hand, expose the same remote service proxy all the time, being able to delegate calls to changing backend stubs (for example, refetched SLSB homes). >>> >>>So what we could do is add an analogous "cacheJndiObject" flag to JndiObjectFactoryBean, with the option to turn it off for refetching on every access - while clients still receive a single reference that does not break. In the latter case, we'd have to expose a proxy that implements the same interfaces as the JNDI object, delegating all calls to the current backend object. This could be useful for SFSB homes and JMS Destinations, particularly during development. >>> >>>Of course, the choice between looking up once and refetching on every access is a bit simplistic. If we could determine that a reference to a JNDI object or RMI proxy is broken, we could apply a more sophisticated strategy, just refetching if actually necessary. Unfortunately, I don't see a reliable way to achieve this for generic JNDI objects. Is there maybe a specific way for EJB homes, JMS Destinations, RMI proxies, respectively? >>> >>> >>> >>> >>> >>> >>I agree that this is the ideal. When you are working with stateless >>objects, the best scenario is one where you only do the lookups again >>when absolutely necessary, i.e. the object is broken. But 'broken' means >>different things for the different kinds of objects. It may even be >>application-specific. >> >> >> >> >> >>>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, as requested by a user some time ago: Local SLSBs can be hot-redeployed too, shutting down the current EJB class loader and starting up a fresh one. So the "cacheHome" flag on our SLSB accessors makes sense for local SLSBs too, particularly during development. Likewise, a "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a local object too, if the server supports hot-redeploying the respective target object. >>> >>>Juergen >>> >>> |
|
From: <jue...@we...> - 2004-09-01 08:17:15
|
The only runtime disadvantage of "lookupHomeOnStartup"=3Dfalse and = "refreshHomeOnConnectFailure"=3Dtrue is that it requires synchronized = access to the home object. However, that's just very minor overhead. =20 Additionally, "lookupHomeOnStartup"=3Dfalse does not eagerly validate, = so misconfiguration will just show on first access rather than on = startup. As you say, the home is simply not available on web container = startup with many EJB containers, so it's probably better to accept late = validation as tradeoff. =20 I guess it makes sense to use the same defaults for the RMI accessors. = After all, an RMI server might start later than the web server, or = restart while the web server stays up. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mi 01.09.2004 05:43 An: spr...@li... Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator I agree that the renaming makes sense. I would go for sure with "lookupHomeOnStartup"=3Dfalse as a default. As for "refreshHomeOnConnectFailure"=3Dtrue, I can't really think of any negative consequences. Code all looks ok to me, I'll give it a runthrough tomorrow. j=FCrgen h=F6ller [werk3AT] wrote: >How do we proceed with the defaults? Should we make = "lookupHomeOnStartup"=3Dfalse and "refreshHomeOnConnectFailure"=3Dtrue = the default? > >FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", = "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to = "lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", = respectively. The RMI docs consistently call that thing "stub", so I = thought we should too, as it also avoids confustion with an AOP proxy as = provided by RmiProxyFactoryBean. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >Gesendet: Mo 30.08.2004 15:56 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator > > > >I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. = Its only disadvantage, aside from backwards compatibility, is that it = requires a synchronized block for accessing the home object, which could = have negative effects in a highly concurrent environment. > >The current implementation tries to avoid synchronization wherever it = can: In particular, "lookupHomeOnStartup"=3Dtrue does not use = synchronization unless you also specified "refreshHomeOnConnectFailure". = Same goes for RmiClientInterceptor and JndiRmiClientInterceptor. > >That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse = and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for = both lazy home lookup and automatic refresh/retry if the home became = stale (for example, after a restart of the target server). > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Sunday, August 29, 2004 5:21 PM >To: spr...@li... >Subject: Re: [Springframework-developer] JNDI object caching and >AbstractJndiLocator > > >I think the enhancements are going to help people. From reading your >mail below (haven't looked at the code yet), it sounds like the >lookupHomeOnStartup option is on by default. I know that this makes the >code completely backwards compatible, but IMHO it probably makes more >sense to have it default to off. In a lot fo containers you had to use >the lazy-init=3Dtrue setting on the bean previously so you wouldn't = access >the ejbs before they were actually loaded, so I think most users will >want this on by default. Of course, there are some people who will get >an error message (on bad setup) later rather than sooner with this >setup, but I think it's going to be less people than get burned by the >fact their EJBs are not loaded yet. > >I'll update the ejbtest integration test/sample at a minimum to test >some of the new options. I should be able to update the ejb docs to >mention the new options. > > >j=FCrgen h=F6ller [werk3AT] wrote: > >=20 > >>Forget to mention that I've also refactored = AbstractRemoteSlsbInvokerInterceptor and = SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching = strategies (as opposed to home fetching strategies) should be = straightforward now. >> >>For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed = with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting = overridden to work on a shared SLSB proxy instance, rather than creating = one for each invocation. The SLSB proxy could be created in an = "afterPropertiesSet" implementation (calling "newSessionBeanInstance") = and removed in a "destroy" implementation (calling = "removeSessionBeanInstance"). >> >>In total, all defaults should behave just like before, but I believe = that the new EJB access options (particularly lazy lookup and refresh on = connect failure) provide significant value for typical usage scenarios. = And the new RMI options increase the value of standalone RMI as remoting = strategy, making them a more credible alternative to HTTP-based = remoting. >> >>Colin, what's your view on these changes? We should discuss any issues = ASAP, to be able to release 1.1 final by the end of the coming week. It = would also be great to discuss those options briefly in the reference = manual - do you maybe have the chance to add some brief paragraphs on = them? >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >>Gesendet: So 29.08.2004 16:27 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator >> >> >> >>Everything's committed since Friday. Everybody who has the chance, = please give the new options a try, in particular the new EJB access = options. I've tested the RMI options quite a bit, but not had a chance = to play with the EJB options yet. >> >>* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" = option (alongside the existing "cacheHome"): Turn it off to get lazy = fetching of the EJB home, on first access, caching the home from then = on. The interceptor respectively proxy bean can still be initialized = eagerly, so there's no need to mark its bean definition as "lazy-init". >> >>* AbstractRemoteSlsbInvokerInterceptor has a new = "refreshHomeOnConnectFailure" option: Turn it on to automatically = refresh the home and retry if a call resulted in a = java.rmi.ConnectException. This should work without side effects, as = ConnectException should just be thrown if no socket connection to the = target server could be established: Retrying the call with a fresh EJB = home should be a safe operation in that case. The default is off, = though. >> >>* RmiClientInterceptor and JndiRmiClientInterceptor have analogous = "lookupRmiProxyOnStartup", "cacheRmiProxy" and = "refreshRmiProxyOnConnectFailure" options. By default, the first two = options are on and the latter is off. Those can in principle be combined = in any way, as they are independent to a large degree. The refresh = option behaves similarly to with EJB homes: It refreshes and retries on = java.rmi.ConnectException. >> >>So there are two main new features for EJB and RMI: lazy = initialization of a cached EJB home without resorting to defining the = bean as "lazy-init", and refreshing the EJB home object respectively RMI = proxy if it became stale. The latter allows for hot restarts of the EJB = respectively RMI server without restarting the client, no matter whether = the EJB home supports auto-failover itself. >> >>This brings the EJB and RMI support to the same convenience level as = the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up = the remote server later than the client or restarting the remote server = without restarting the client does not pose a problem for HTTP-based = remoting in the first place, as there is no proxy holding a connection = that could become stale there. Therefore, the above options are not = necessary for the HTTP remoting support in the first place. >> >>Juergen >> >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] >>Gesendet: Mi 25.08.2004 21:23 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator >> >> >> >>I've basically finished the reworked proxy fetching stuff: = RmiClientInterceptor, JndiRmiClientInterceptor and = AbstractSlsbInvokerInterceptor all support the four fetching strategies = I've mentioned, through two flags (look proxy up on startup, cache = proxy). As those accessors are capable of refetching the proxy now, we = can also easily allow for further strategies, for example to check a = proxy and refetch if it is broken (with custom check implementation). >> >>I've also added a JndiObjectTargetSource that can be used to refetch a = JNDI object for each call. It supports two analogous flags, so the = actual fetching strategy can be customized. I've tested this with an = OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus = JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each = createConnection call can trigger a fresh JNDI lookup to make sure that = the ConnectionFactory reference is valid. >> >>While refetching of RMI proxies and JNDI objects for each operation of = course represents a significant overhead, it's not too bad if the = respective objects are rarely used. I still rather consider this as = development feature, though, to allow restarting of remote processes = while keeping the clients alive. Lazily initializing the references is a = good feature for production too: The remote processes do not have to be = alive when the clients start up then. >> >>I'll commit all of that stuff tomorrow, after having gone through it = in terms of documentation etc. I'll also put some further thought into = custom refetching strategies, providing appropriate hooks for = subclasses. In the future, we might introduce an appropriate strategy = interface for that. >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag = von Colin Sampaleanu >>Gesendet: Mi 25.08.2004 15:08 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] JNDI object caching and = AbstractJndiLocator >> >> >> >>j=FCrgen h=F6ller [werk3AT] wrote: >> >> >> >> =20 >> >>>One further thing: JndiObjectFactoryBean currently returns its = located object as-is for the entire lifetime of the client application: = If the located object becomes broken at some point of time (which can = happen, for example, to an SFSB home or a JMS Destination), clients will = carry an unusable reference from then on. Our remoting accessors, on the = other hand, expose the same remote service proxy all the time, being = able to delegate calls to changing backend stubs (for example, refetched = SLSB homes). >>> >>>So what we could do is add an analogous "cacheJndiObject" flag to = JndiObjectFactoryBean, with the option to turn it off for refetching on = every access - while clients still receive a single reference that does = not break. In the latter case, we'd have to expose a proxy that = implements the same interfaces as the JNDI object, delegating all calls = to the current backend object. This could be useful for SFSB homes and = JMS Destinations, particularly during development. >>> >>>Of course, the choice between looking up once and refetching on every = access is a bit simplistic. If we could determine that a reference to a = JNDI object or RMI proxy is broken, we could apply a more sophisticated = strategy, just refetching if actually necessary. Unfortunately, I don't = see a reliable way to achieve this for generic JNDI objects. Is there = maybe a specific way for EJB homes, JMS Destinations, RMI proxies, = respectively? >>> >>> >>>=20 >>> >>> =20 >>> >>I agree that this is the ideal. When you are working with stateless >>objects, the best scenario is one where you only do the lookups again >>when absolutely necessary, i.e. the object is broken. But 'broken' = means >>different things for the different kinds of objects. It may even be >>application-specific. >> >> >> >> =20 >> >>>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, = as requested by a user some time ago: Local SLSBs can be hot-redeployed = too, shutting down the current EJB class loader and starting up a fresh = one. So the "cacheHome" flag on our SLSB accessors makes sense for local = SLSBs too, particularly during development. Likewise, a = "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a = local object too, if the server supports hot-redeploying the respective = target object. >>> >>>Juergen >>> =20 >>> ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-08-25 12:14:40
|
You can keep around an SLSB stub and use it for multiple calls, but you have to be very careful that all requests do not go through this one stub, as it will potentially become a point of serialization. So this is really viable only if you also do pooling to handle simultaneous requests. About 4 years ago, I once had to try to help optimize a WebLogic based app that somebody did, where they decided to be smart, and cached just one SLSB stub in the ServletContext. This stub was used for servicing _all_ requests. Basically WebLogic serialized all requests through the stub. The app could handle less than 5 requests a second. After I suggested going away from the shared stub, along with some small db optimizations, the app was able to handle 75 requests a second... Colin jürgen höller [werk3AT] wrote: >I've actually changed AbstractJndiLocator's internal workings: Subclasses are supposed to explicitly call a "lookup()" method now, receiving the freshly located object, rather than getting a "located(Object)" callback on startup. This is necessary to implement true hot fetching of the JNDI object (just in time for calling a method on it, and throwing it away again right afterwards), without temporarily storing it in an instance variable. > >In terms of backwards compatibility, it's probably better to keep the AbstractJndiLocator as-is (deprecating it though) and put the new code into a JndiObjectLocator base class. Our remoting proxies can then derive from that new base class, with explicit lookup calls whenever they need them. > >There's actually four strategies that we could support out-of-the-box: >1. look up the JNDI object on bean initialization, storing it for later usage >2. look up the JNDI object on bean initialization (to determine interfaces or for validation), refetching it for every operation >3. look up the JNDI object on first need (first call to JndiObjectLocator.lookup), storing it for later usage >4. look up the JNDI object for every operation (every call to JndiObjectLocator.lookup) > >Number 1 is current standard behavior. Number 3 requires synchronized access to the stored JNDI object, but seems to be the appropriate behavior for EJB lookups (avoiding lazy-init on the bean and all objects that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during development; number 2 does the same, but performs early validation, assuming that the lookup already works on startup. > >Regarding usage of remote EJB homes: What alternative strategies are there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do more efficiently if you accept some assumptions about your server? I could imagine that on some servers, creating the SLSB instance once and keeping it for the lifetime of the client application would work: Often, the SLSB instance is just a proxy that creates new calls to the servers every time, not allocating any resources on the server... > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Di 24.08.2004 21:01 >An: spr...@li... >Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator > > > >I don't think it's a big deal if AbstractJndiLocator doesn't do an >immediate lookup on initialization. I actually complained about the fact >that it did this a while ago, and this is why most people are >recommended to make their EJB proxies lazy, since a lot of the time the >JNDI tree is not ready at the time the JNDI lookup is done, if the proxy >is not set as ready, depending on the EJB environment. I would be >surprised if too many people are using this class, as opposed to >JndiObjectFactoryBean... Is this the only thing you want to change in >AbstractJndiLocator? > >As for the question about remote communication on the usage of the home, >I don't think there's any guarantees here. A clustering EJB >implementation could very well do some remote communication on create >calls, if that makes the job of the cluster management code easier. It >is typically the bean stub itself that handles cluster failover, so I >dont think the home object actually has any real need to do remote >communications, but I don't remember there being any contract forbidding >it. I'm working from memory, but I do seem to remember that EJB 2.0 does >recommend that you now stay in your own VM, when creating a new stub, >for efficiency reasons. I.e. load balancing is no longer supposed to be >handled by automatically (by default) handing off to EJBs on different >cluster members, with that being recommended only for failover. > >Colin > >jürgen höller [werk3AT] wrote: > > > >>I've just checked remote proxy caching throughout our remoting strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, allowing to perform a fresh lookup if turned off. Analogously, JndiRmiClientInterceptor should be able to refetch its JNDI object now if the flag is turned off. >> >>Our EJB accessors have a similar "cacheHome" flag, which was implemented a bit crudely: If turned off, it simply overwrote the instance variable for the home object on every invocation - in a non-thread-safe manner. Preferably, it should simply fetch a new temporary proxy on each invocation in that case, just like RmiClientInterceptor does. >> >>Unfortunately, this means that our AbstractJndiLocator base class should change: It should not perform a lookup on initialization in any case and call located, but rather allow subclasses to explicitly call lookup when needed (i.e. either on initialization or on each invocation, depending on the respective flag). >> >>I've already adapted everything accordingly: All our remote accessors (which are based on proxies that need lookup, i.e. not the HTTP-based ones) have consistent support for configurable caching of proxies now. >> >>The question is: Can we live with the incompatible change in AbstractJndiLocator class (which is somewhat internal anyway)? Else, I could introduce a different base class for the above use case. However, that one would be very similar to the old AbstractJndiLocator, and we don't really have a need for the old locator class anymore... >> >>----- >> >>On a related note: Does a create call on a remote SLSB home usually involve actual remote communication, or is it rather implemented as local operation that returns a proxy for an actual SLSB instance? I was wondering whether our SimpleSlsbInvokerInterceptor actually causes communication overhead through its create call for each method invocation... >> >>Juergen >> >> |
