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: 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.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.
