I've been working on this a little bit more and have concluded that the
better way to resolve it is to reverse the meaning of that argument to
update, so that true means local only, and false means local and remote.
This makes it consistent with the other methods of cache. I'm also going
to eliminate the updateExclude method. I also think we should phase out
the LOCAL_INVOCATION and REMOTE_INVOCATION constants because they are
_REALLY_ confusing.
Opinions? Votes?
-- jt
On Thu, 2002-05-16 at 13:03, James Taylor wrote:
> While setting up a TCP lateral I encountered an infinite loop (sending
> an element to a peer, getting it back, putting it, sending it again...).
> To resolve it I made the following change:
>
>
> public void handlePut( ICacheElement element )
> throws IOException
> {
> if ( log.isDebugEnabled() )
> {
> log.debug( "handlePut> cacheName=" + element.getCacheName() + ", key=" +
>element.getKey() );
> }
>
> // This was the following, however passing true in for updateRemotes
> // causes an a loop, since the element will the be sent to the sender.
> // Passing false in fixes things, but I'm not sure I understand all
> // the details yet.
> //
> // getCache( element.getCacheName() )
> // .update( element, CacheConstants.REMOTE_INVOKATION );
>
> getCache( element.getCacheName() )
> .update( element, false );
> }
>
> Does passing false (or LOCAL_INVOCATION) in there make sense? Things
> work much better now (vs OutOfMemory errors)
>
> -- jt
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
