RE: [jbosscache-dev] RE: [javagroups-users] Possible speedup of voidRPC response
by Ben Wang
Actually, PojoCache would need to use RPC layer for some functionality as well. So key is where will this be coming from?
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Wednesday, August 30, 2006 4:36 PM
To: Brian Stansberry
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] RE: [javagroups-users] Possible speedup of voidRPC response
Sounds like a need for a dedicated RPC layer. :-)
I think being able to register a marshaller for return values is certainly a good thing though - I can think of 2 places where this can currently be a problem in JBC (although I haven't seen anyone speak of them yet): clustered cache loaders and data gravitation, both of which expect return values from RPC calls.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 29 Aug 2006, at 16:09, Brian Stansberry wrote:
> (Moving to this list a thread related to a new 2.4 feature for using a
> JGroups Marshaller for marshalling RPC responses as well as requests.)
>
> Bela Ban wrote:
>> Brian Stansberry wrote:
>>> I haven't had a chance to do the CPU profile, but did run the AS
>>> testsuite.
>>>
>>> Using the registered Marshaller for return marshalling leads to all
>>> sorts of problems; the specialized marshallers in JBoss Cache
>>> weren't
>>> designed to marshal responses, so all hell breaks loose. A ton of
>>> session replication test cases fail.
>>
>> What do you mean by "were not designed" ? Is there a chance
>> we can make it work rather than introducing the kludge below ?
>>
>
> The JBC marshallers were written assuming all they had to do was
> marshal/unmarshal a MethodCall, which is all that was required
> before. I
> haven't looked in detail, but wouldn't be surprised if there are casts
> to MethodCall. Beyond just failing, if region-based marshalling is in
> effect, using it for responses would be very inefficient. If
> region-based marshalling is in effect, the marshaller writes the Fqn
> string at the start of the stream so it can be parsed out by the
> unmarshaller and used to check if the region is active and if the call
> should be made. If the call isn't region-specific (e.g. a call used
> for
> buddy group formation), "NULL" is written. So, if we used the current
> marshaller for a response, the string "NULL" would be written for
> every
> void response.
>
> These things can be fixed going forward, but the kludge was needed to
> make 2.4 usable with existing releases of JBoss Cache.
>
>> Besides, don't you have classloader problems when JGroups
>> (rather than the Marshaller) unmarshalls values ? Because, by
>> default,
>> Util.objectFromByteBuffer() simply uses the system classloader !
>>
>
> The only objects ever included in a response are JBC exceptions. This
> *would* be a problem if JBC were loaded by a different classloader
> than
> JGroups. I've never heard any complaint about this, so I guess people
> don't configure it that way (JBoss AS certainly doesn't.)
>
>>> How about adding a property
>>> RpcDispatcher.setResponseMarshaller(Marshaller m)? If set, the
>>> Marshaller gets passed through to RequestCorrelator. If not, the old
>>> behavior remains, which is backward compatible.
>>>
>>> I've attached a patch that does that. With this in place, the
>>> failing tests all pass again.
>>>
>>> Having the ability to marshal responses would definitely be a good
>>> thing for the JBoss HAPartition. For JBC, your optimized Util method
>>> should be fine, as all that's ever returned is null or an exception
>>
>> Okay, I'll apply this patch, but could you please create a
>> JIRA issue to look into using the same Marshaller that's used
>> for incoming requests ?
>
> Thanks. JIRAs are http://jira.jboss.com/jira/browse/JBCACHE-752 and
> http://jira.jboss.com/jira/browse/JBAS-3583 .
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 2 months
RE: [javagroups-users] Possible speedup of void RPC response
by Brian Stansberry
(Moving to this list a thread related to a new 2.4 feature for using a
JGroups Marshaller for marshalling RPC responses as well as requests.)
Bela Ban wrote:
> Brian Stansberry wrote:
>> I haven't had a chance to do the CPU profile, but did run the AS
>> testsuite.
>>
>> Using the registered Marshaller for return marshalling leads to all
>> sorts of problems; the specialized marshallers in JBoss Cache weren't
>> designed to marshal responses, so all hell breaks loose. A ton of
>> session replication test cases fail.
>
> What do you mean by "were not designed" ? Is there a chance
> we can make it work rather than introducing the kludge below ?
>
The JBC marshallers were written assuming all they had to do was
marshal/unmarshal a MethodCall, which is all that was required before. I
haven't looked in detail, but wouldn't be surprised if there are casts
to MethodCall. Beyond just failing, if region-based marshalling is in
effect, using it for responses would be very inefficient. If
region-based marshalling is in effect, the marshaller writes the Fqn
string at the start of the stream so it can be parsed out by the
unmarshaller and used to check if the region is active and if the call
should be made. If the call isn't region-specific (e.g. a call used for
buddy group formation), "NULL" is written. So, if we used the current
marshaller for a response, the string "NULL" would be written for every
void response.
These things can be fixed going forward, but the kludge was needed to
make 2.4 usable with existing releases of JBoss Cache.
> Besides, don't you have classloader problems when JGroups
> (rather than the Marshaller) unmarshalls values ? Because, by default,
> Util.objectFromByteBuffer() simply uses the system classloader !
>
The only objects ever included in a response are JBC exceptions. This
*would* be a problem if JBC were loaded by a different classloader than
JGroups. I've never heard any complaint about this, so I guess people
don't configure it that way (JBoss AS certainly doesn't.)
>> How about adding a property
>> RpcDispatcher.setResponseMarshaller(Marshaller m)? If set, the
>> Marshaller gets passed through to RequestCorrelator. If not, the old
>> behavior remains, which is backward compatible.
>>
>> I've attached a patch that does that. With this in place, the
>> failing tests all pass again.
>>
>> Having the ability to marshal responses would definitely be a good
>> thing for the JBoss HAPartition. For JBC, your optimized Util method
>> should be fine, as all that's ever returned is null or an exception
>
> Okay, I'll apply this patch, but could you please create a
> JIRA issue to look into using the same Marshaller that's used
> for incoming requests ?
Thanks. JIRAs are http://jira.jboss.com/jira/browse/JBCACHE-752 and
http://jira.jboss.com/jira/browse/JBAS-3583 .
18 years, 2 months
Re: CacheLoader list of affected files
by Manik Surtani
OK. Let me know when you're done with them.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 29 Aug 2006, at 21:31, Vladimir Blagojevic wrote:
> Manik,
>
> I am including list of affected files. Would it be ok for you to
> hold of
> commits on these files for another day or two so I can make sure that
> all the tests pass and that everything is ok. Is there a public junit
> report somewhere online related to latest JBC build(s)?
>
> Here is the list of affected files:
>
> org.jboss.cache.loader
>
> AsyncCacheLoader
> CacheLoader
> ChainingCacheLoader
> ClusteredCacheLoader
> DelegatingCacheLoader
> FileCacheLoader
> JDBCCacheLoader
> LocalDelegatingCacheLoader
> NodeData
> RmiDelegatingCacheLoader
> RpcDelegatingCacheLoader
> SharedStoreCacheLoader
> TcpDelegatingCacheLoader
>
> org.jboss.cache.loader.bdbje
>
> BdbjeCacheLoader
>
> org.jboss.cache.loader.jdbm
>
> JdbmCacheLoader
>
> org.jboss.cache.loader.tcp
> TcpCacheServer
>
> org.jboss.cache.statetransfer
>
> all files
>
>
> In tests/functional
>
>
> org.jboss.cache.loader
>
> AsyncFileCacheLoaderTest
> BdbjeTest
> CacheLoaderTestBase
> DummyCacheLoader
> ExtendedCacheLoaderTestBase
> InterceptorSynchronizationTest
>
> org.jboss.cache.passivation
>
> PassivationTestBase
>
> org.jboss.cache.statetransfer
>
> all files
>
>
>
18 years, 2 months
RE: [jbosscache-dev] Method storeEntireState is ambiguous with null parameter
by Vladimir Blagojevic
Yeah I agree with your concerns. I am not a performance expert but as I
see it our
performance improvement boundary ends when we reach the contents of
cache (value object in NodeData attrs map). Unless we force customers
to implement some special interfaces there is not much more we can do?
So in summary we move forward with Cacheloader API that has only 4
load/store methods:
void loadEntireState(ObjectOutputStream os) throws Exception;
void storeEntireState(ObjectInputStream is) throws Exception;
void loadState(Fqn subtree,ObjectOutputStream os) throws Exception;
void storeState(Fqn subtree,ObjectInputStream is) throws Exception;
Please hold of any work on all cacheloaders until the end of the week if
possible.
> -----Original Message-----
> From: Bela Ban
> Sent: Tuesday, August 29, 2006 12:26 PM
> To: Vladimir Blagojevic
> Cc: Manik Surtani; jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Method storeEntireState is
> ambiguous with null parameter
>
> I understand your reasoning, but what I'm asking is "is the
> NodeData marshalling mechanism efficient ?". Or - since there
> are not yet too many CacheLoader implementations *which
> interact with each other* - should we come up with a
> (potentially) more efficient marshalling format ? See, I
> wrote that format down some time ago, and wasn't too
> concerned about efficiency.
>
18 years, 3 months
RE: [jbosscache-dev] Method storeEntireState is ambiguous with null parameter
by Vladimir Blagojevic
But it will be almost impossible for this hypothetical cacheloader
implementor to decode the state using ByteBuffer and follow
interoperability requirement. Since we have to keep interoperability
between all cacheloaders the exact sequence of stream (un)wrapping has
to be used. For example if byte based FileCacheLoader writes a state ,
as it does now like this:
ByteArrayOutputStream out_stream=new
ByteArrayOutputStream(1024);
ObjectOutputStream out=new
MarshalledValueOutputStream(out_stream);
loadStateFromFilessystem(subtree, out);
out.close();
return out_stream.toByteArray();
then the cacheloader reader of this state has to reverse these exact
streams unless they really reallly know what they are doing.
If we have 4 stream based methods then we (StateTransferIntegrator and
StateTransferGenerator) control which streams we pass to cacheloader
implementors. They have to read/write NodeData objects (as per contract)
to the stream anyway and there is never a problem of stream corruption.
Cacheloader implementors only worry about reading/writing NodeData
objects.
> -----Original Message-----
> From: Bela Ban
> Sent: Tuesday, August 29, 2006 8:53 AM
> To: Vladimir Blagojevic
> Cc: Manik Surtani; jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Method storeEntireState is
> ambiguous with null parameter
>
> +1 from me, although some folks might like the simplicity of byte[].
> Although, to unmarshal, most folks will create an input
> stream off of the byte array anyway.
>
> Oops, NO, this doesn't work ! What about people who'd like to
> use java.nio.ByteBuffer ? There is *no* stream notion in NIO !!!
>
> E.g.
>
> byte[] state;
> ByteBuffer buf=ByteBuffer.wrap(state);
> buf.getInt();
> bug.getLong();
> etc etc
>
> Okay, I change my vote to -1...
>
> Vladimir Blagojevic wrote:
> > We really should.
> >
> > In the light of our recent conversations it really does not
> make sense
> > to keep byte based methods. Cacheloader implementors can
> easily make a
> > mistake and disrupt interoperability with other cacheloader
> > implementations. Another argument for having only 4 stream based
> > methods is that cacheloader implementors do not have to implement
> > separate methods for streaming and byte based transfer.
> >
> > Brian and I talked about this extensively.
> >
> > Let have another vote on this.
> >
> >
> >
> >> -----Original Message-----
> >> From: Manik Surtani [mailto:manik@jboss.org]
> >> Sent: Tuesday, August 29, 2006 8:01 AM
> >> To: Vladimir Blagojevic
> >> Cc: jbosscache-dev(a)lists.jboss.org
> >> Subject: Re: [jbosscache-dev] Method storeEntireState is ambiguous
> >> with null parameter
> >>
> >> Are we not going to pull the byte[] methods from the interface, as
> >> per your conversation with Brian?
> >> --
> >> Manik Surtani
> >>
> >> Lead, JBoss Cache
> >> JBoss, a division of Red Hat
> >>
> >> Email: manik(a)jboss.org
> >> Telephone: +44 7786 702 706
> >> MSN: manik(a)surtani.org
> >> Yahoo/AIM/Skype: maniksurtani
> >>
> >>
> >> On 25 Aug 2006, at 17:25, Vladimir Blagojevic wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> As you might be aware Cacheloader 2.0 will add 4 methods
> >>>
> >> for streaming
> >>
> >>> state transfer:
> >>>
> >>> void storeEntireState(InputStream s); void storeState(Fqn
> >>> subtree,InputStream s); void loadEntireState(OutputStream
> s); void
> >>> loadState(Fqn subtree,OutputStream s);
> >>>
> >>> There is a slight problem will method overloading, namely
> >>>
> >> we have now
> >>
> >>> two methods:
> >>>
> >>> void storeEntireState(byte[] state) throws Exception; void
> >>> storeEntireState(InputStream is) throws Exception;
> >>>
> >>> which are properly overloaded. However, java compiler will
> >>>
> >> complain if
> >>
> >>> somebody invokes
> >>>
> >>> cacheloader.storeEntireState(null);
> >>>
> >>> Workaround is to declare actual parameter explicitly , i.e:
> >>>
> >>>
> >>> byte [] nullstate = null;
> >>> cacheloader.storeEntireState(nullstate);
> >>>
> >>> so that compiler can distinguish which overloaded method
> to invoke.
> >>> This is the case with our own BdbjeTest that was invoking
> >>> cl.storeEntireState(null);
> >>>
> >>> Does anyone have any complaints or concerns? If not, I
> >>>
> >> would proceed
> >>
> >>> with adding stream based methods to CacheLoader and adding noop
> >>> implementation methods to all implementers of CacheLoader
> interface.
> >>>
> >>> _______________________________________________
> >>> jbosscache-dev mailing list
> >>> jbosscache-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >>>
> >>
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >
> >
>
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group JBoss - a
> division of Red Hat
>
>
18 years, 3 months
RE: [jbosscache-dev] Stream dilemma
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yes, this sounds good. Make sure the Cache Loader interface
> is appropriately javadoc'd to this effect though, so
> implementors satisfy the contract - especially the implicit
> parts about not closing the stream, not catching exceptions, etc.
>
We can probably implement a simple object stream wrapper class that
disables close().
>> So basically the contract with object based streams obliges
>> cacheloader implementors as following:
>>
>> - they are not allowed to close the stream
>> - they should not catch any exceptions
>> - they should not wrap the provided object stream
>>
>> And it gives us (state transfer generators/integrators) all the
>> flexibility we need:
>>
>> - we keep control of which stream we pass
>> - we keep the reference to the passed stream
>> - we keep control of stream closing and exception handling
>>
>> If this contract is violated we lose interoperability between various
>> cacheloaders, cacheloader implementations are very error prone and it
>> becomes very hard for state transfer generators/integrators to
>> correctly implement state transfers.
18 years, 3 months
RE: [jbosscache-dev] Method storeEntireState is ambiguous with null parameter
by Vladimir Blagojevic
We really should.
In the light of our recent conversations it really does not make sense
to keep byte based methods. Cacheloader implementors can easily make a
mistake and disrupt interoperability with other cacheloader
implementations. Another argument for having only 4 stream based methods
is that cacheloader implementors do not have to implement separate
methods for streaming and byte based transfer.
Brian and I talked about this extensively.
Let have another vote on this.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, August 29, 2006 8:01 AM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Method storeEntireState is
> ambiguous with null parameter
>
> Are we not going to pull the byte[] methods from the
> interface, as per your conversation with Brian?
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> On 25 Aug 2006, at 17:25, Vladimir Blagojevic wrote:
>
> > Hi,
> >
> > As you might be aware Cacheloader 2.0 will add 4 methods
> for streaming
> > state transfer:
> >
> > void storeEntireState(InputStream s);
> > void storeState(Fqn subtree,InputStream s); void
> > loadEntireState(OutputStream s); void loadState(Fqn
> > subtree,OutputStream s);
> >
> > There is a slight problem will method overloading, namely
> we have now
> > two methods:
> >
> > void storeEntireState(byte[] state) throws Exception; void
> > storeEntireState(InputStream is) throws Exception;
> >
> > which are properly overloaded. However, java compiler will
> complain if
> > somebody invokes
> >
> > cacheloader.storeEntireState(null);
> >
> > Workaround is to declare actual parameter explicitly , i.e:
> >
> >
> > byte [] nullstate = null;
> > cacheloader.storeEntireState(nullstate);
> >
> > so that compiler can distinguish which overloaded method to invoke.
> > This is the case with our own BdbjeTest that was invoking
> > cl.storeEntireState(null);
> >
> > Does anyone have any complaints or concerns? If not, I
> would proceed
> > with adding stream based methods to CacheLoader and adding noop
> > implementation methods to all implementers of CacheLoader interface.
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
18 years, 3 months
Method storeEntireState is ambiguous with null parameter
by Vladimir Blagojevic
Hi,
As you might be aware Cacheloader 2.0 will add 4 methods for streaming
state transfer:
void storeEntireState(InputStream s);
void storeState(Fqn subtree,InputStream s);
void loadEntireState(OutputStream s);
void loadState(Fqn subtree,OutputStream s);
There is a slight problem will method overloading, namely we have now
two methods:
void storeEntireState(byte[] state) throws Exception;
void storeEntireState(InputStream is) throws Exception;
which are properly overloaded. However, java compiler will complain if
somebody invokes
cacheloader.storeEntireState(null);
Workaround is to declare actual parameter explicitly , i.e:
byte [] nullstate = null;
cacheloader.storeEntireState(nullstate);
so that compiler can distinguish which overloaded method to invoke.
This is the case with our own BdbjeTest that was invoking
cl.storeEntireState(null);
Does anyone have any complaints or concerns? If not, I would proceed
with adding
stream based methods to CacheLoader and adding noop implementation
methods to all
implementers of CacheLoader interface.
18 years, 3 months
RE: [jbosscache-dev] Stream dilemma
by Vladimir Blagojevic
So basically the contract with object based streams obliges cacheloader
implementors as following:
- they are not allowed to close the stream
- they should not catch any exceptions
- they should not wrap the provided object stream
And it gives us (state transfer generators/integrators) all the
flexibility we need:
- we keep control of which stream we pass
- we keep the reference to the passed stream
- we keep control of stream closing and exception handling
If this contract is violated we lose interoperability between various
cacheloaders, cacheloader implementations are very error prone and it
becomes very hard for state transfer generators/integrators to correctly
implement state transfers.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Vladimir Blagojevic
> Sent: Monday, August 28, 2006 10:40 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Stream dilemma
>
> Brian and I talked privately about changing CacheLoader API
> to use object based stream parameters rather than plain
> input/output streams.
> Please comment.
>
> -----Original Message-----
> From: Brian Stansberry
> Sent: Saturday, August 26, 2006 2:29 PM
> To: Vladimir Blagojevic
> Subject: RE: Stream dilemma
>
> I much prefer the latter. Earlier on a thread about this we
> determined we wanted cross-CacheLoader interoperability and
> thus were going to formally specify the format of the state
> as a sequence of serialized NodeData objects. Therefore by
> the interface contract the cache loader must use an
> ObjectInput/OutputSteam to do its job; it's not like the
> loader implementor has freedom to use some
> com.xyz.CustomStateEncodingInput/OutputStream. Given that,
> providing the ObjectInput/OutputStream to the cache loader
> makes a lot more sense for the reasons you stated. The
> CacheLoader's job is simply to read the objects and store
> them; it shouldn't have access to the stream underlying the
> ObjectInput/OutputStream as providing that access limits the
> flexibility of the StateTransferGenerator/Integrator.
>
> Once you provide the ObjectInput/OutputStream, that also
> logically implies that the overloaded methods with the byte[]
> should go away.
> Either the CacheLoader has to know how to manage the
> lifecycle of an ObjectInput/OutputStream or it doesn't.
>
> Vladimir Blagojevic wrote:
> > Hey Brian,
> >
> > I am trying to find the best solution for persistent state
> > loading/storing and I want to bounce this off you.
> >
> > Dilemma is whether to allow cacheloader implementers to create and
> > close the stream themselves in load/store cacheloader
> implementations
> > or not. If we keep current API signature with
> InputStream/OutputStream
>
> > then cacheloader implementers have to wrap this stream with
> a variant
> > of ObjectInputStream/ObjectOutputStream and then if they
> create this
> > stream then they have to close it themselves. Which is fine
> I believe
> > because we write/read persistent state last in state
> transfer. We also
>
> > have to rely on cacheloader implementers that they know
> what they are
> > doing. They might not for example propagate io exceptions to us and
> > thus we have no idea that something went wrong.
> >
> > If we change current API signature to accept
> > ObjectInputStream/ObjectOutputStream then we sort of have
> more control
>
> > about which stream we pass to cacheloader implementers (we have
> > reference to that stream), more control about closing it and we
> > require less intelligence from cacheloader implementers
> about dealing
> > with these streams.
> > They simply read/write and do not catch any io exceptions and let
> > everything propagate to the caller.
> >
> > I know I have not summarized this nicely. I am just sort of
> thinking
> > out loud.
> >
> > All the best,
> > Vladimir
>
>
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years, 3 months
JBCACHE-470 : MUX integration
by Manik Surtani
Hi Jerry/Brian,
Is this complete in HEAD as well as the 140 Branch? Also, has it
been documented and can this be closed?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 3 months