[infinispan-dev] ISPN-872 - MIME type for pure binary forms?

[Galder Zamarreño]

On Jan 13, 2011, at 11:26 AM, Michal Linhard wrote:

> (sending again, I'm not sure the first mail went through)
> 
> Since we're discussing this, I've been wondering (since ISPN-714), why 
> do we treat MIME "application/x-java-serialized-object" specially in the 
> first place ?
> 
> Why does REST server try to deserialize the bytes once it discovers they 
> are "application/x-java-serialized-object" ?
> Is there any special argument supporting this behaviour ? I could 
> imagine some, if we wanted to share data between server modules, but so 
> far this is not desirable.
> Is it more space-optimal to store it this way? But then what about 
> time-optimality ?

I did have a think about this, and the advantage that I see is that you deserialize an object, this can also be accessed from within the same JVM directly. So, you could access your object both remotely and from within the JVM. 

I'm not sure how realistic this is though cos any code running in same JVM would need to get hold of the CacheManager used by the REST server, and it's not very clear how you'd do that and we don't really advertise this capability.

> I know REST interface is not directed primarily towards java clients, 
> but still I guess
> "application/x-java-serialized-object" can be quite popular MIME choice, 
> and since REST server does serialization and deserializaition for each 
> such request,
> this might even become a performance issue. (if we ignore possibility to 
> use HotRod, which is obviously more suitable for java clients)
> 
> I guess with HotRod and Memcached server module no such deserialization 
> takes place ... only the client knows the meaning of the bytes it feeds 
> the cache.

Yeah, Hot Rod and Memcached definitely do no deserialization because they're not type aware. They treat whatever comes as simply byte[] and make no assumptions about it.

> 
> Michal.
> 
> On 01/13/2011 09:44 AM, Galder Zamarreño wrote:
>> Hi all,
>> 
>> Re: https://issues.jboss.org/browse/ISPN-872
>> 
>> As stated in my last comment, it appears to me that Infinispan's REST server is not distinguishing between a byte array that comes from a Java client that serialized an object, and a pure byte[] that is not necessarily a serialized form of a Java object.
>> 
>> The test added by Michal might not make sense to a lot of you (http://goo.gl/8qfnw - testByteArrayStorage), but the underlying issue is still present.
>> 
>> Looking back at past tests, IntegrationTest.testSerializedObjects is not correct. The byte array passed is not "application/x-java-serialized-object". In fact, the server tries to deserialize it and fails, which leads to the byte[] being stored as is, but still under the "application/x-java-serialized-object" banner.
>> 
>> My question is, what should be the type to use for pure byte arrays? Should it be "application/octet-stream" ? Any other suggestions?
>> 
>> Cheers,
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> -- 
> Michal Linhard
> Quality Assurance Engineer
> 
> Red Hat Czech s.r.o.
> Purkynova 99 612 45 Brno, Czech Republic
> phone: +420 532 294 320 ext. 62320
> mobile: +420 728 626 363
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache