The server side can use nio, while clients are limited to the number of remote
services they can access by the number of threads and memory capacity of the
jvm.
No one has asked for nio on clients.
Scale out is still an option, just depends on how how much processing you do vs
network comms.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Sent: 05/02/2017 10:34:09 pm
To: dev@river.apache.org
Subject: Re: Serialization issues
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.klec...@xpro.biz>
> Sent: 05/02/2017 04:04:03 am
> To: d...@riverapache.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.klec...@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.klec...@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.klec...@xpro.biz> <michal.klec...@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<j...@zeus.net.au> <j...@zeus.net.au>
><j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au> <j...@zeus.net.au>
> <j...@zeus.net.au> <j...@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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
