river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: Serialization issues
Date Sun, 05 Feb 2017 12:34:09 GMT
It is performant - no doubt about it.
But it is not scalable because your scalability is limited not by 
network speed but the maximum number of threads.

Thanks,
Michal

Peter wrote:
> The other catch is that shared mutable state also needs to be synchronized.
>
> Still River 3.0 should be running at close to raw socket speed, it has the worlds most
scalable security manager and fastest URLClassLoader.  The multiplexer in jeri allows 127
different remote objects to share the same connection between two endpoints.
>
> Cheers,
>
> Peter.
>
> Sent from my Samsung device.
>   
>    Include original message
> ---- Original message ----
> From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
> Sent: 05/02/2017 04:04:03 am
> To: dev@river.apache.org
> Subject: Re: Serialization issues
>
> You do not have to do any IO in readObject/writeObject.
>
> The fact that you have readObject/writeObject methods means that you are forced to do
blocking IO.
> It is simple:
>
> readObject(...) {
>    ois.defaultReadObject();
>    //the above line MUST be blocking because
>    verifyMyState();
>    //this line expects the data to be read
> }
>
> Siilarly:
>
> writeObject(ObjectOutputStream oos) {
>    oos.writeInt(whateverField);
>    //buffers full? You need to block, sorry
>    oos.writeObject(...)
> }
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
> I am asking what Network I/O you are doing in the readObject/writeObject
> methods. Because to me I can't figure out any use-case where that is a
> problem...
>
> On Sun, Feb 5, 2017 at 1:14 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<
> michal.kleczek@xpro.biz>  wrote:
>
> Don't know about other serialization uses but my issue with it is that it
> precludes using it in non-blocking IO.
> Sorry if I haven't been clear enough.
>
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> And what I/O (network I/O I presume) are you doing during the serialization
> (without RMI)?
>
> On Sun, Feb 5, 2017 at 12:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
 wrote:
>
>
> It is not possible to do non-blocking as in "non blocking IO" - meaning -
> threads do not block on IO operations.
> Just google "C10K problem"
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> I don't follow. What does readObject/writeObject got to do with blocking or
> not? You could spin up executors to do the work in parallel if you so wish.
> And why is "something else" less blocking? And what are you doing that is
> "blocking" since the "work" is (or should be) CPU only, there is limited
> (still) opportunity to do that non-blocking (whatever that would mean in
> CPU-only circumstance). Feel free to elaborate... I am curious.
>
>
>
> On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
 <michal.kleczek@xpro.biz>
>   wrote:
>
>
> Unfortunately due to "writeObject" and "readObject" methods that have to
> be handled (to comply with the spec) - it is not possible to
> serialize/deserialize in a non-blocking fashion.
> So yes... - it is serialization per se.
>
> Thanks,
> Michal
>
> Niclas Hedhman wrote:
>
> Oh, well that is not "Serialization" per se... No wonder i didn't get it.
>
> On Sat, Feb 4, 2017 at 7:20 PM, Peter<jini@zeus.net.au>  <jini@zeus.net.au>
 <jini@zeus.net.au>  <jini@zeus.net.au>  <jini@zeus.net.au>  <jini@zeus.net.au>
 <jini@zeus.net.au>  <jini@zeus.net.au>  wrote:
>
>
> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>
>
> but rather with the APIs - it is inherently blocking by design.
>
> I am not sure I understand what you mean by that.
>
>
>
> He means the client thread that makes the remote call blocks waiting for
> the remote end to process the request and respond.
>
> Cheers,
>
> Peter.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message