1. Yes, you can buffer the whole object graph as long as it is small enough.
2. In the end threads are just abstraction on top of inherently serial
machine that produces asynchronous events (CPU with interrupts)
providing a nice programming in languages that do not support monads.
It might be worth investigating http://www.paralleluniverse.co/quasar/
for River.
OTOH I have also read papers about handling C10M problem. These guys are
serious :) .
The general conclusion is that any "general" abstraction (such as
threads) breaks. Any context switches are no-no.
So you implement the full event (interrupt) driven network stack in user
space - the architecture somewhat similar to an exokernel.
See https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4
But we are diverging...
Cheers,
Michal
Niclas Hedhman wrote:
Ok, but assuming that you are not talking about GB-sized object graphs, it
is more an issue with RMI than Serialization, because you can create
non-blocking I/O "on top", just like Jetty has non-blocking I/O "on top" of
the equally blocking Servlet API. Right? I assume that there is a similar
thing in Tomcat, because AFAIK Google AppEngine runs on Tomcat
It is not required (even it is) that the ObjectOutputStream is directly
connected to the underlying OS file descriptor. I am pretty sure that it
would be a mistake trying to re-design all software that writes to a stream
to have a non-blocking design.
Additionally, while looking into this, I came across
https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html,
which might be to your interest. Not totally relevant, but still an
interesting read.
Cheers
On Sun, Feb 5, 2017 at 2:04 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<
michal.klec...@xpro.biz> wrote:
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> <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> <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> <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.
