4:41 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache