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. > > > > > > > > > > > > -- Niclas Hedhman, Software Developer http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
