Quantcast

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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Galder Zamarreño
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Linhard
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
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 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.

Michal.

--
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Linhard
In reply to this post by Galder Zamarreño
(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 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.

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
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Manik Surtani
In reply to this post by Galder Zamarreño
It makes sense not to deserialize this in the first place.  E.g., treat applictaion/x-java-serialized-object the same as application/octet-stream.  Deserializing is a Bad Thing, the server nodes may not even have the necessary class definitions to be able to deserialize.


On 13 Jan 2011, at 08:44, 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Galder Zamarreño
Good point about classloading. I'll go ahead with that.

On Jan 13, 2011, at 2:38 PM, Manik Surtani wrote:

> It makes sense not to deserialize this in the first place.  E.g., treat applictaion/x-java-serialized-object the same as application/octet-stream.  Deserializing is a Bad Thing, the server nodes may not even have the necessary class definitions to be able to deserialize.
>
>
> On 13 Jan 2011, at 08:44, 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...