[jbosscache-dev] Method storeEntireState is ambiguous with null parameter

[Bela Ban]

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.

But, you're right, if we provide an InputStream, we could still use 
ByteBuffers to read chunks of data from it. So, +1 for streams from me

Vladimir Blagojevic wrote:
> 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 at 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 at jboss.org]
>>>> Sent: Tuesday, August 29, 2006 8:01 AM
>>>> To: Vladimir Blagojevic
>>>> Cc: jbosscache-dev at 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 at jboss.org
>>>> Telephone: +44 7786 702 706
>>>> MSN: manik at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>>       
>>>>>           
>>>>     
>>>>         
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at 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
>>
>>
>>     
>
>   

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat