.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
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 no
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
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
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.)"
Sent: 05/02/2017 04:04:03 am
To: dev@river.apache.org
Subject: Re: Serialization issues
You do not have to
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 wo
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
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 exp
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 u
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,
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 I
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 th
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
11 matches
Mail list logo
