Here's code reference (for netty-3.6.6)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(). Go to
abstract function read(SelectionKey k) . The go to
org.jboss.netty.channel.socket.nio.NioWorker.read() implementation. This
block:
...
try {
while ((ret = ch.read(bb)) > 0) {
readBytes += ret;
if (!bb.hasRemaining()) {
break;
}
}
failure = false;
} catch (ClosedChannelException e) {
// Can happen, and does not need a user attention.
} catch (Throwable t) {
fireExceptionCaught(channel, t);
}
...
So they read and catch ClosedChannelException. And then further they call
close(channel, succeededFuture(channel)); which means that operation on
channel will not pass.
2013/12/11 artemv zmq <[email protected]>
> hi Justin,
>
> >> If the server goes down, and their is an established session, there
> is no way to know that without further communication, or no response where
> response is expected.
> >> If there is, I would love to know about it.
>
> I found a solution. There's a lib in java called "netty". So they do
> next: in separate thread they poll existing channels on read operation
> (among others) and during this poll __they can__ detect
> that "socket was focibly closed by remote peer". Ok? So they just poll
> for read and when things are connected polling on read returns an info
> akin to "0 bytes was read", so essentially, appl. treat this like "nothing
> was read but channel is alive!". And that's it. What it gives? Before
> write operation we may know the status of channel. "0 bytes read" is an
> indicator that it's alive. If got exception -- channel is closed, and all
> future operations on channel are cancelled.
>
> I'm wondering why ZMQ can't do something similar or even better? o_O
>
>
> BR
> -artemv
>
>
>
> 2013/12/11 artemv zmq <[email protected]>
>
>> Cool! I saw Bruno response. Justin, thanks for patience and for keep
>> replying, I much appreciate that.
>>
>>
>> BR
>> -artemv
>>
>>
>>
>> 2013/12/11 Justin Cook <[email protected]>
>>
>>> Artem,
>>>
>>> There is no way to know that a node on the network went down without the
>>> lack of receiving acknowledgements that the message was received — either
>>> with TCP ACKs or a messaging pattern in 0MQ such as REQ/REP.
>>>
>>> If the the server is not up yet, and you have not established a session,
>>> then Bruno has given you the option to workaround that. If the server goes
>>> down, and their is an established session, there is no way to know that
>>> without further communication, or no response where response is expected.
>>>
>>> If there is, I would love to know about it.
>>>
>>> --
>>> Justin Cook
>>>
>>>
>>> On Wednesday, 11 December 2013 at 10:42, artemv zmq wrote:
>>>
>>> > hi Justin. Thanks for heads up.
>>> >
>>> > Ok. Clear. Especially about steady stream.
>>> >
>>> > But, again, let me make it very clear.
>>> > I imagine following situations and desired outcomes:
>>> > - Server is not up yet, and client tries to send a message. Desired
>>> outcome: big red alarm -- "fail" w/o waiting for reply.
>>> > - Server is up, client sends a message, gets reply, everything is
>>> smooth. Then the network between client and server is getting down (e.g.
>>> "ifdown eth0" on server). The client tries to send a message... Desired
>>> outcome: big red alarm -- "fail" w/o waiting for reply.
>>> >
>>> > I don't care server is up or down, or in what status an infrastructure
>>> is. I want to know one thing -- did all frames (of my message) been sent or
>>> not ?
>>> >
>>> > Is it posible with ZMQ?
>>> >
>>> >
>>> > BR
>>> > -artemv
>>> >
>>> >
>>> >
>>> > 2013/12/11 Justin Cook <[email protected] (mailto:[email protected])>
>>> > > Artem,
>>> > >
>>> > > This is a problem that every network developer faces. Did my message
>>> make it to its destination? If I send a message, is it likely to make it to
>>> the recipient?
>>> > >
>>> > > Fortunately, there are patterns to use to increase reliability, but
>>> even then there is no way to be 100% sure that when a message is sent, it
>>> will flow across the infrastructure and be delivered with 100% certainty
>>> without an acknowledgement.
>>> > >
>>> > > You cannot _instantly_ get an indication a server failed — or the
>>> associated infrastructure — unless you have a steady stream of bytes going
>>> across the wire, and they suddenly stop. If you want to know a node went
>>> down, you will need heartbeat messages. There are a few ways to do this.
>>> > >
>>> > > Please look at the paranoid pirate example and this:
>>> > >
>>> > > http://zguide.zeromq.org/page:all#Heartbeating
>>> > >
>>> > > --
>>> > > Justin Cook
>>> > >
>>> > >
>>> > > On Wednesday, 11 December 2013 at 09:59, artemv zmq wrote:
>>> > >
>>> > > > Okay. Thanks for your thoughts. Again, I read the guide, and I
>>> know on practice what's pub/sub/push/pull/ .. and so on.
>>> > > >
>>> > > > But let me ask one more time very concrete and simple question. I
>>> want to develop a client/server appl. Okay. I pick dealer/router pattern.
>>> Fine. Now my requirement is following:
>>> > > > if server is unaccessible (wrong ip address, server is not online,
>>> server was online and then went offline, etc.) -- in this case I want to
>>> get (_instantly_) some indication that client can't send a message because
>>> server is unaccessible. It's clear? Again, I don't want to await for reply,
>>> I want to know right now that I can't send a message.
>>> > > >
>>> > > > Realistically, this is very classic networking issue :) So, how
>>> can ZMQ help me? Or is it possible/eligible et al to implement
>>> transactional (not batching!) applications on ZMQ?
>>> > > >
>>> > > >
>>> > > > BR
>>> > > > -artemv
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > 2013/12/11 Bruno D. Rodrigues <[email protected] (mailto:
>>> [email protected]) (mailto:[email protected])>
>>> > > > > zeromq.org (http://zeromq.org) (http://zeromq.org) - learn the
>>> basics - http://zeromq.org/intro:read-the-manual - the guide -
>>> http://zguide.zeromq.org/page:all
>>> > > > >
>>> > > > > I just gave you a short description of how Ømq is solving the
>>> network problems for me.
>>> > > > >
>>> > > > > On Dec 11, 2013, at 6:59, asif saeed <[email protected](mailto:
>>> [email protected]) (mailto:[email protected])> wrote:
>>> > > > > > Hi Bruno,
>>> > > > > >
>>> > > > > > On Wed, Dec 11, 2013 at 12:38 AM, Bruno D. Rodrigues <
>>> [email protected] (mailto:[email protected]) (mailto:
>>> [email protected])> wrote:
>>> > > > > > > Xsub xpub for distribution load balancing
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > What is Xsub xpub? Could you please explain these terms or
>>> give me a link to an online resource where these terms are explained in
>>> detail?
>>> > > > > >
>>> > > > > > Thanks in advance,
>>> > > > > > -Asif
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > _______________________________________________
>>> > > > > > zeromq-dev mailing list
>>> > > > > > [email protected] (mailto:
>>> [email protected]) (mailto:[email protected])
>>> > > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > _______________________________________________
>>> > > > > zeromq-dev mailing list
>>> > > > > [email protected] (mailto:[email protected])
>>> (mailto:[email protected])
>>> > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > > >
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > zeromq-dev mailing list
>>> > > > [email protected] (mailto:[email protected])
>>> (mailto:[email protected])
>>> > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > zeromq-dev mailing list
>>> > > [email protected] (mailto:[email protected])
>>> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > [email protected] (mailto:[email protected])
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> [email protected]
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
