On Saturday, February 16, 2013 12:02:21 AM Emmanuel Lécharny wrote:
> There is a time issue : you can have a client which has just sent some
> data at T0, which will be sent to the server at T0+n, with the server
> which as sent a "sending-disabled' at T0+x, where T0+x is < T0 + n. In
> this case, there is no way for the client to stop the message it as
> already sent, even if it's still somewhere between the client and the
> server.
>
> The sender thread never lock the channel : it tries to write the data
> into it, and either it succeeded in one operation, or it has just wrote
> a part of the data, and will wait for the channel to be ready for a new
> write (ie, the socket is ready to accept some new data). If the thread
> can't write all the data, it just stack it into a queue, which will be
> read again when the channel is ready for sending some new data, which
> may be done a long time after. It's perfectly possible that in the mean
> time, the cient receives a sending-disabled, but still, the message is
> considered as sent.
>
> > Briefly, I want to make a check when the session.write() method locks
the
> > channel. Can I do this, how?
>
> No, you can't, because the channel is never locked. Or 'locks' stands
> for something different, and you need to be a bit more explicit.
You got me totally right.
>
> What exactly do you want to do ? Is this interrupting some sending if a
> message is received from the server ?
I am trying to send a message only once to the server but it seems
impossible
in the scope of non-blocking communication and my enable/disable conditions.
Assume receiver thread takes the processor from sender thread before
sending
is not completed. And, receiver takes a disable message:
Checking the client state before write() method may cause a missing
message:
Client writes message to the session. Receiver thread takes the processor.
Receiver takes a disable message. When, the sender has the processor again,
it
sends the message but server does not take into account a client's message
after disabling it. However, client thinks that the message has been sent.
if(state==sending_enabled):
session.write(...)
Checking the client state after write() method may cause duplication:
Client
writes message to the session and waits for the completion. After
completion,
receiver thread takes the processor between two if statement below.
Receiver
takes a disable message. Then, sender thread takes the processor again.
Checks
the state and resends the messages for second time.
FutureWriter fWriter = session.write(...)
fWriter.join()
if(fWriter.isWritten()):
if(state==sending_disabled):
mark this message as not send. try to send again when sending
enabled
- o -
On the other hand, interrupting the sending queue after taking a disable
message may cause a loss too. Consider the following code:
messageReceived(message):
if(message==sending_disabled):
list = session.getSendingQueue()
session.cancelSendingQueue()
addToResendList(list)
Receiver takes a disable message and tries to cancel sending queue. Before
canceling (calling cancelSendingQueue()), sender thread gains the processor
and sends the message. Now, client thinks the message has been sent but
server
has just ignored it. Message is lost.
2013/2/16 Emmanuel Lécharny <elecha...@gmail.com>
> Le 2/15/13 10:20 PM, Ricardo Cristian Ramirez a écrit :
> > I have a client application which has a sending state. If sending state
> is
> > enabled, this means client can send something to the server and if it is
> > disabled, client can not send anything. Sending state is directed by
> > server, i.e. server sends a message "sending_enabled" and client's state
> > changes. And, when client's sending state is disabled, it should not
> send
> > anything to the server.
> >
> > Currently, I have a mina client application whose connector is
> > NioSocketConnector. On the client side, I use session.write() method for
> > sending data. However, in order to achieve the above situation, I have to
> > do some extra thing. Consider the below situation:
> >
> > check the client state before sending -> assume that sending is enabled,
> so
> > we can send our data
> > call session.write(...) -> code inside the write() method is being
> executed
> > Now, assume that before locking the channel in the sender thread, it has
> > lost the processor. Then, receiver thread takes the processor and got a
> > message which says "sending_disabled". Hence, client's state is changed.
> > When the sender thread takes the processor again, our message will be
> sent
> > to the server without checking the client's state. However, that
> > message should not send.
> There is a time issue : you can have a client which has just sent some
> data at T0, which will be sent to the server at T0+n, with the server
> which as sent a "sending-disabled' at T0+x, where T0+x is < T0 + n. In
> this case, there is no way for the client to stop the message it as
> already sent, even if it's still somewhere between the client and the
> server.
>
> The sender thread never lock the channel : it tries to write the data
> into it, and either it succeeded in one operation, or it has just wrote
> a part of the data, and will wait for the channel to be ready for a new
> write (ie, the socket is ready to accept some new data). If the thread
> can't write all the data, it just stack it into a queue, which will be
> read again when the channel is ready for sending some new data, which
> may be done a long time after. It's perfectly possible that in the mean
> time, the cient receives a sending-disabled, but still, the message *is*
> considered as sent.
> >
> > Briefly, I want to make a check when the session.write() method locks the
> > channel. Can I do this, how?
> No, you can't, because the channel is never locked. Or 'locks' stands
> for something different, and you need to be a bit more explicit.
>
> What exactly do you want to do ? Is this interrupting some sending if a
> message is received from the server ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
