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