You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Valentin Kulichenko <va...@gmail.com> on 2017/01/05 22:02:09 UTC
Timeout for ordered message
Folks,
Anyone knows what is the purpose of the timeout for
IgniteMessaging#sendOrdered method?
void sendOrdered(@Nullable Object topic, Object msg, long timeout);
It seems to me that in current implementation messages are always ordered
on communication level. I.e. if you send messages 1, 2 and 3, there is no
way to receive 3 before 2. The only difference between ordered and
unordered messages is that ordered are processed one after another in a
single thread, while unordered can be processed in parallel.
Having said that, timeout for ordered messages doesn't make much sense to
me. Is there a scenario that I'm missing?
-Val
Re: Timeout for ordered message
Posted by Valentin Kulichenko <va...@gmail.com>.
Makes sense. I created a ticket:
https://issues.apache.org/jira/browse/IGNITE-4595
-Val
On Mon, Jan 23, 2017 at 3:05 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Val, let's do the following.
>
> 1. We need to state in javadocs that we expect unordered msg handler to be
> added in advance, otherwise message get ignored. This may require user
> should have an ability to add listeners before start (same as in case with
> event listeners) - or can this be done in lifecycle listener? I think no.
> 2. You can add overload for ordered msg sending without timeout and explain
> in javadoc that this will work similar to endless timeout.
>
> Makes sense?
>
>
> --Yakov
>
> 2017-01-13 0:54 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com
> >:
>
> > Yakov,
> >
> > I'm talking only about user messages and public API. What is the purpose
> of
> > the timeout in this case?
> >
> > I'm just trying to properly understand the semantics and at least fix the
> > JavaDoc as it seems to be completely wrong now.
> >
> > -Val
> >
> > On Thu, Jan 12, 2017 at 2:41 AM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> >
> > > Not sure what we are trying to achieve here. Unordered messages are
> > simply
> > > ignored if there is no listener. We always expect unordered listeners
> to
> > be
> > > installed before at least for internal messages, but this is not the
> case
> > > for some ordered messages, i.e. task session requests.
> > >
> > > --Yakov
> > >
> > > 2017-01-12 0:03 GMT+03:00 Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com
> > > >:
> > >
> > > > Yakov,
> > > >
> > > > So you confirm that my understanding is correct and JavaDoc is wrong,
> > > > right?
> > > >
> > > > As for 'no listener' scenario, that's a good point, but it should be
> > > > applicable to unordered messages as well then. The most confusing
> part
> > > here
> > > > is that we have timeout only for unordered messages while there is
> > > nothing
> > > > specific about them in terms of delivery.
> > > >
> > > > How about we two methods, with and without timeout, for both ordered
> > and
> > > > unordered messages? Like this:
> > > >
> > > > void send(@Nullable Object topic, Object msg);
> > > > void send(@Nullable Object topic, Object msg, long timeout); // New
> > > method.
> > > > void sendOrdered(@Nullable Object topic, Object msg); // New method.
> > > > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> > > >
> > > > This change will make API consistent and will not break
> compatibility.
> > > > Thoughts?
> > > >
> > > > -Val
> > > >
> > > > On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov <yzhdanov@apache.org
> >
> > > > wrote:
> > > >
> > > > > If you send ordered messages to a node and listener on receiving
> side
> > > has
> > > > > not yet been added then timeout is still sufficient to clean up
> > > buffered
> > > > > messages.
> > > > >
> > > > > --Yakov
> > > > >
> > > > > 2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com>:
> > > > >
> > > > > > Yakov,
> > > > > >
> > > > > > I was actually asking about the public API for messaging
> > > > > > (IgniteMessaging#sendOrdered
> > > > > > method). Here is the JavaDoc:
> > > > > >
> > > > > > * The {@code timeout} parameter specifies how long an
> out-of-order
> > > > > message
> > > > > > will stay in a queue,
> > > > > > * waiting for messages that are ordered ahead of it to arrive.
> If
> > > > > timeout
> > > > > > expires, then all ordered
> > > > > > * messages that have not arrived before this message will be
> > > skipped.
> > > > > When
> > > > > > (and if) expired messages
> > > > > > * actually do arrive, they will be ignored.
> > > > > >
> > > > > > I remember that we indeed had this scenario possible a while ago,
> > but
> > > > > then
> > > > > > implementation of ordered messaging was reworked and
> 'out-of-order
> > > > > message'
> > > > > > can't happen anymore. Is this correct? If so, I think the timeout
> > > > should
> > > > > be
> > > > > > removed from the API.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <
> > > yzhdanov@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Val, timeout still makes sense for task sessions. It is
> possible
> > > that
> > > > > all
> > > > > > > jobs mapped to node have been completed, but node still
> receives
> > > > > > > attributes. Attributes are sent in ordered messages. It may
> > happen
> > > so
> > > > > > that
> > > > > > > node may start processing jobs for that task again and this way
> > all
> > > > the
> > > > > > > attributes will be available. If task timeout elapses then
> > messages
> > > > get
> > > > > > > cleared. Please let me know if you still have questions.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > --
> > > > > > > Yakov Zhdanov, Director R&D
> > > > > > > *GridGain Systems*
> > > > > > > www.gridgain.com
> > > > > > >
> > > > > > > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > > > > > > valentin.kulichenko@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Anyone knows what is the purpose of the timeout for
> > > > > > > > IgniteMessaging#sendOrdered method?
> > > > > > > >
> > > > > > > > void sendOrdered(@Nullable Object topic, Object msg, long
> > > timeout);
> > > > > > > >
> > > > > > > > It seems to me that in current implementation messages are
> > always
> > > > > > ordered
> > > > > > > > on communication level. I.e. if you send messages 1, 2 and 3,
> > > there
> > > > > is
> > > > > > no
> > > > > > > > way to receive 3 before 2. The only difference between
> ordered
> > > and
> > > > > > > > unordered messages is that ordered are processed one after
> > > another
> > > > > in a
> > > > > > > > single thread, while unordered can be processed in parallel.
> > > > > > > >
> > > > > > > > Having said that, timeout for ordered messages doesn't make
> > much
> > > > > sense
> > > > > > to
> > > > > > > > me. Is there a scenario that I'm missing?
> > > > > > > >
> > > > > > > > -Val
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Timeout for ordered message
Posted by Yakov Zhdanov <yz...@apache.org>.
Val, let's do the following.
1. We need to state in javadocs that we expect unordered msg handler to be
added in advance, otherwise message get ignored. This may require user
should have an ability to add listeners before start (same as in case with
event listeners) - or can this be done in lifecycle listener? I think no.
2. You can add overload for ordered msg sending without timeout and explain
in javadoc that this will work similar to endless timeout.
Makes sense?
--Yakov
2017-01-13 0:54 GMT+03:00 Valentin Kulichenko <valentin.kulichenko@gmail.com
>:
> Yakov,
>
> I'm talking only about user messages and public API. What is the purpose of
> the timeout in this case?
>
> I'm just trying to properly understand the semantics and at least fix the
> JavaDoc as it seems to be completely wrong now.
>
> -Val
>
> On Thu, Jan 12, 2017 at 2:41 AM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
> > Not sure what we are trying to achieve here. Unordered messages are
> simply
> > ignored if there is no listener. We always expect unordered listeners to
> be
> > installed before at least for internal messages, but this is not the case
> > for some ordered messages, i.e. task session requests.
> >
> > --Yakov
> >
> > 2017-01-12 0:03 GMT+03:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com
> > >:
> >
> > > Yakov,
> > >
> > > So you confirm that my understanding is correct and JavaDoc is wrong,
> > > right?
> > >
> > > As for 'no listener' scenario, that's a good point, but it should be
> > > applicable to unordered messages as well then. The most confusing part
> > here
> > > is that we have timeout only for unordered messages while there is
> > nothing
> > > specific about them in terms of delivery.
> > >
> > > How about we two methods, with and without timeout, for both ordered
> and
> > > unordered messages? Like this:
> > >
> > > void send(@Nullable Object topic, Object msg);
> > > void send(@Nullable Object topic, Object msg, long timeout); // New
> > method.
> > > void sendOrdered(@Nullable Object topic, Object msg); // New method.
> > > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> > >
> > > This change will make API consistent and will not break compatibility.
> > > Thoughts?
> > >
> > > -Val
> > >
> > > On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov <yz...@apache.org>
> > > wrote:
> > >
> > > > If you send ordered messages to a node and listener on receiving side
> > has
> > > > not yet been added then timeout is still sufficient to clean up
> > buffered
> > > > messages.
> > > >
> > > > --Yakov
> > > >
> > > > 2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com>:
> > > >
> > > > > Yakov,
> > > > >
> > > > > I was actually asking about the public API for messaging
> > > > > (IgniteMessaging#sendOrdered
> > > > > method). Here is the JavaDoc:
> > > > >
> > > > > * The {@code timeout} parameter specifies how long an out-of-order
> > > > message
> > > > > will stay in a queue,
> > > > > * waiting for messages that are ordered ahead of it to arrive. If
> > > > timeout
> > > > > expires, then all ordered
> > > > > * messages that have not arrived before this message will be
> > skipped.
> > > > When
> > > > > (and if) expired messages
> > > > > * actually do arrive, they will be ignored.
> > > > >
> > > > > I remember that we indeed had this scenario possible a while ago,
> but
> > > > then
> > > > > implementation of ordered messaging was reworked and 'out-of-order
> > > > message'
> > > > > can't happen anymore. Is this correct? If so, I think the timeout
> > > should
> > > > be
> > > > > removed from the API.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <
> > yzhdanov@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Val, timeout still makes sense for task sessions. It is possible
> > that
> > > > all
> > > > > > jobs mapped to node have been completed, but node still receives
> > > > > > attributes. Attributes are sent in ordered messages. It may
> happen
> > so
> > > > > that
> > > > > > node may start processing jobs for that task again and this way
> all
> > > the
> > > > > > attributes will be available. If task timeout elapses then
> messages
> > > get
> > > > > > cleared. Please let me know if you still have questions.
> > > > > >
> > > > > > Thanks!
> > > > > > --
> > > > > > Yakov Zhdanov, Director R&D
> > > > > > *GridGain Systems*
> > > > > > www.gridgain.com
> > > > > >
> > > > > > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > > > > > valentin.kulichenko@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > Anyone knows what is the purpose of the timeout for
> > > > > > > IgniteMessaging#sendOrdered method?
> > > > > > >
> > > > > > > void sendOrdered(@Nullable Object topic, Object msg, long
> > timeout);
> > > > > > >
> > > > > > > It seems to me that in current implementation messages are
> always
> > > > > ordered
> > > > > > > on communication level. I.e. if you send messages 1, 2 and 3,
> > there
> > > > is
> > > > > no
> > > > > > > way to receive 3 before 2. The only difference between ordered
> > and
> > > > > > > unordered messages is that ordered are processed one after
> > another
> > > > in a
> > > > > > > single thread, while unordered can be processed in parallel.
> > > > > > >
> > > > > > > Having said that, timeout for ordered messages doesn't make
> much
> > > > sense
> > > > > to
> > > > > > > me. Is there a scenario that I'm missing?
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Timeout for ordered message
Posted by Valentin Kulichenko <va...@gmail.com>.
Yakov,
I'm talking only about user messages and public API. What is the purpose of
the timeout in this case?
I'm just trying to properly understand the semantics and at least fix the
JavaDoc as it seems to be completely wrong now.
-Val
On Thu, Jan 12, 2017 at 2:41 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Not sure what we are trying to achieve here. Unordered messages are simply
> ignored if there is no listener. We always expect unordered listeners to be
> installed before at least for internal messages, but this is not the case
> for some ordered messages, i.e. task session requests.
>
> --Yakov
>
> 2017-01-12 0:03 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com
> >:
>
> > Yakov,
> >
> > So you confirm that my understanding is correct and JavaDoc is wrong,
> > right?
> >
> > As for 'no listener' scenario, that's a good point, but it should be
> > applicable to unordered messages as well then. The most confusing part
> here
> > is that we have timeout only for unordered messages while there is
> nothing
> > specific about them in terms of delivery.
> >
> > How about we two methods, with and without timeout, for both ordered and
> > unordered messages? Like this:
> >
> > void send(@Nullable Object topic, Object msg);
> > void send(@Nullable Object topic, Object msg, long timeout); // New
> method.
> > void sendOrdered(@Nullable Object topic, Object msg); // New method.
> > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> >
> > This change will make API consistent and will not break compatibility.
> > Thoughts?
> >
> > -Val
> >
> > On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> >
> > > If you send ordered messages to a node and listener on receiving side
> has
> > > not yet been added then timeout is still sufficient to clean up
> buffered
> > > messages.
> > >
> > > --Yakov
> > >
> > > 2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com>:
> > >
> > > > Yakov,
> > > >
> > > > I was actually asking about the public API for messaging
> > > > (IgniteMessaging#sendOrdered
> > > > method). Here is the JavaDoc:
> > > >
> > > > * The {@code timeout} parameter specifies how long an out-of-order
> > > message
> > > > will stay in a queue,
> > > > * waiting for messages that are ordered ahead of it to arrive. If
> > > timeout
> > > > expires, then all ordered
> > > > * messages that have not arrived before this message will be
> skipped.
> > > When
> > > > (and if) expired messages
> > > > * actually do arrive, they will be ignored.
> > > >
> > > > I remember that we indeed had this scenario possible a while ago, but
> > > then
> > > > implementation of ordered messaging was reworked and 'out-of-order
> > > message'
> > > > can't happen anymore. Is this correct? If so, I think the timeout
> > should
> > > be
> > > > removed from the API.
> > > >
> > > > -Val
> > > >
> > > > On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <
> yzhdanov@gridgain.com>
> > > > wrote:
> > > >
> > > > > Val, timeout still makes sense for task sessions. It is possible
> that
> > > all
> > > > > jobs mapped to node have been completed, but node still receives
> > > > > attributes. Attributes are sent in ordered messages. It may happen
> so
> > > > that
> > > > > node may start processing jobs for that task again and this way all
> > the
> > > > > attributes will be available. If task timeout elapses then messages
> > get
> > > > > cleared. Please let me know if you still have questions.
> > > > >
> > > > > Thanks!
> > > > > --
> > > > > Yakov Zhdanov, Director R&D
> > > > > *GridGain Systems*
> > > > > www.gridgain.com
> > > > >
> > > > > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > > > > valentin.kulichenko@gmail.com
> > > > > >:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Anyone knows what is the purpose of the timeout for
> > > > > > IgniteMessaging#sendOrdered method?
> > > > > >
> > > > > > void sendOrdered(@Nullable Object topic, Object msg, long
> timeout);
> > > > > >
> > > > > > It seems to me that in current implementation messages are always
> > > > ordered
> > > > > > on communication level. I.e. if you send messages 1, 2 and 3,
> there
> > > is
> > > > no
> > > > > > way to receive 3 before 2. The only difference between ordered
> and
> > > > > > unordered messages is that ordered are processed one after
> another
> > > in a
> > > > > > single thread, while unordered can be processed in parallel.
> > > > > >
> > > > > > Having said that, timeout for ordered messages doesn't make much
> > > sense
> > > > to
> > > > > > me. Is there a scenario that I'm missing?
> > > > > >
> > > > > > -Val
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Timeout for ordered message
Posted by Yakov Zhdanov <yz...@apache.org>.
Not sure what we are trying to achieve here. Unordered messages are simply
ignored if there is no listener. We always expect unordered listeners to be
installed before at least for internal messages, but this is not the case
for some ordered messages, i.e. task session requests.
--Yakov
2017-01-12 0:03 GMT+03:00 Valentin Kulichenko <valentin.kulichenko@gmail.com
>:
> Yakov,
>
> So you confirm that my understanding is correct and JavaDoc is wrong,
> right?
>
> As for 'no listener' scenario, that's a good point, but it should be
> applicable to unordered messages as well then. The most confusing part here
> is that we have timeout only for unordered messages while there is nothing
> specific about them in terms of delivery.
>
> How about we two methods, with and without timeout, for both ordered and
> unordered messages? Like this:
>
> void send(@Nullable Object topic, Object msg);
> void send(@Nullable Object topic, Object msg, long timeout); // New method.
> void sendOrdered(@Nullable Object topic, Object msg); // New method.
> void sendOrdered(@Nullable Object topic, Object msg, long timeout);
>
> This change will make API consistent and will not break compatibility.
> Thoughts?
>
> -Val
>
> On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
> > If you send ordered messages to a node and listener on receiving side has
> > not yet been added then timeout is still sufficient to clean up buffered
> > messages.
> >
> > --Yakov
> >
> > 2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com>:
> >
> > > Yakov,
> > >
> > > I was actually asking about the public API for messaging
> > > (IgniteMessaging#sendOrdered
> > > method). Here is the JavaDoc:
> > >
> > > * The {@code timeout} parameter specifies how long an out-of-order
> > message
> > > will stay in a queue,
> > > * waiting for messages that are ordered ahead of it to arrive. If
> > timeout
> > > expires, then all ordered
> > > * messages that have not arrived before this message will be skipped.
> > When
> > > (and if) expired messages
> > > * actually do arrive, they will be ignored.
> > >
> > > I remember that we indeed had this scenario possible a while ago, but
> > then
> > > implementation of ordered messaging was reworked and 'out-of-order
> > message'
> > > can't happen anymore. Is this correct? If so, I think the timeout
> should
> > be
> > > removed from the API.
> > >
> > > -Val
> > >
> > > On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <yz...@gridgain.com>
> > > wrote:
> > >
> > > > Val, timeout still makes sense for task sessions. It is possible that
> > all
> > > > jobs mapped to node have been completed, but node still receives
> > > > attributes. Attributes are sent in ordered messages. It may happen so
> > > that
> > > > node may start processing jobs for that task again and this way all
> the
> > > > attributes will be available. If task timeout elapses then messages
> get
> > > > cleared. Please let me know if you still have questions.
> > > >
> > > > Thanks!
> > > > --
> > > > Yakov Zhdanov, Director R&D
> > > > *GridGain Systems*
> > > > www.gridgain.com
> > > >
> > > > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com
> > > > >:
> > > >
> > > > > Folks,
> > > > >
> > > > > Anyone knows what is the purpose of the timeout for
> > > > > IgniteMessaging#sendOrdered method?
> > > > >
> > > > > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> > > > >
> > > > > It seems to me that in current implementation messages are always
> > > ordered
> > > > > on communication level. I.e. if you send messages 1, 2 and 3, there
> > is
> > > no
> > > > > way to receive 3 before 2. The only difference between ordered and
> > > > > unordered messages is that ordered are processed one after another
> > in a
> > > > > single thread, while unordered can be processed in parallel.
> > > > >
> > > > > Having said that, timeout for ordered messages doesn't make much
> > sense
> > > to
> > > > > me. Is there a scenario that I'm missing?
> > > > >
> > > > > -Val
> > > > >
> > > >
> > >
> >
>
Re: Timeout for ordered message
Posted by Valentin Kulichenko <va...@gmail.com>.
Yakov,
So you confirm that my understanding is correct and JavaDoc is wrong, right?
As for 'no listener' scenario, that's a good point, but it should be
applicable to unordered messages as well then. The most confusing part here
is that we have timeout only for unordered messages while there is nothing
specific about them in terms of delivery.
How about we two methods, with and without timeout, for both ordered and
unordered messages? Like this:
void send(@Nullable Object topic, Object msg);
void send(@Nullable Object topic, Object msg, long timeout); // New method.
void sendOrdered(@Nullable Object topic, Object msg); // New method.
void sendOrdered(@Nullable Object topic, Object msg, long timeout);
This change will make API consistent and will not break compatibility.
Thoughts?
-Val
On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> If you send ordered messages to a node and listener on receiving side has
> not yet been added then timeout is still sufficient to clean up buffered
> messages.
>
> --Yakov
>
> 2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com>:
>
> > Yakov,
> >
> > I was actually asking about the public API for messaging
> > (IgniteMessaging#sendOrdered
> > method). Here is the JavaDoc:
> >
> > * The {@code timeout} parameter specifies how long an out-of-order
> message
> > will stay in a queue,
> > * waiting for messages that are ordered ahead of it to arrive. If
> timeout
> > expires, then all ordered
> > * messages that have not arrived before this message will be skipped.
> When
> > (and if) expired messages
> > * actually do arrive, they will be ignored.
> >
> > I remember that we indeed had this scenario possible a while ago, but
> then
> > implementation of ordered messaging was reworked and 'out-of-order
> message'
> > can't happen anymore. Is this correct? If so, I think the timeout should
> be
> > removed from the API.
> >
> > -Val
> >
> > On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <yz...@gridgain.com>
> > wrote:
> >
> > > Val, timeout still makes sense for task sessions. It is possible that
> all
> > > jobs mapped to node have been completed, but node still receives
> > > attributes. Attributes are sent in ordered messages. It may happen so
> > that
> > > node may start processing jobs for that task again and this way all the
> > > attributes will be available. If task timeout elapses then messages get
> > > cleared. Please let me know if you still have questions.
> > >
> > > Thanks!
> > > --
> > > Yakov Zhdanov, Director R&D
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> > > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com
> > > >:
> > >
> > > > Folks,
> > > >
> > > > Anyone knows what is the purpose of the timeout for
> > > > IgniteMessaging#sendOrdered method?
> > > >
> > > > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> > > >
> > > > It seems to me that in current implementation messages are always
> > ordered
> > > > on communication level. I.e. if you send messages 1, 2 and 3, there
> is
> > no
> > > > way to receive 3 before 2. The only difference between ordered and
> > > > unordered messages is that ordered are processed one after another
> in a
> > > > single thread, while unordered can be processed in parallel.
> > > >
> > > > Having said that, timeout for ordered messages doesn't make much
> sense
> > to
> > > > me. Is there a scenario that I'm missing?
> > > >
> > > > -Val
> > > >
> > >
> >
>
Re: Timeout for ordered message
Posted by Yakov Zhdanov <yz...@apache.org>.
If you send ordered messages to a node and listener on receiving side has
not yet been added then timeout is still sufficient to clean up buffered
messages.
--Yakov
2017-01-10 23:36 GMT+03:00 Valentin Kulichenko <
valentin.kulichenko@gmail.com>:
> Yakov,
>
> I was actually asking about the public API for messaging
> (IgniteMessaging#sendOrdered
> method). Here is the JavaDoc:
>
> * The {@code timeout} parameter specifies how long an out-of-order message
> will stay in a queue,
> * waiting for messages that are ordered ahead of it to arrive. If timeout
> expires, then all ordered
> * messages that have not arrived before this message will be skipped. When
> (and if) expired messages
> * actually do arrive, they will be ignored.
>
> I remember that we indeed had this scenario possible a while ago, but then
> implementation of ordered messaging was reworked and 'out-of-order message'
> can't happen anymore. Is this correct? If so, I think the timeout should be
> removed from the API.
>
> -Val
>
> On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > Val, timeout still makes sense for task sessions. It is possible that all
> > jobs mapped to node have been completed, but node still receives
> > attributes. Attributes are sent in ordered messages. It may happen so
> that
> > node may start processing jobs for that task again and this way all the
> > attributes will be available. If task timeout elapses then messages get
> > cleared. Please let me know if you still have questions.
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com
> > >:
> >
> > > Folks,
> > >
> > > Anyone knows what is the purpose of the timeout for
> > > IgniteMessaging#sendOrdered method?
> > >
> > > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> > >
> > > It seems to me that in current implementation messages are always
> ordered
> > > on communication level. I.e. if you send messages 1, 2 and 3, there is
> no
> > > way to receive 3 before 2. The only difference between ordered and
> > > unordered messages is that ordered are processed one after another in a
> > > single thread, while unordered can be processed in parallel.
> > >
> > > Having said that, timeout for ordered messages doesn't make much sense
> to
> > > me. Is there a scenario that I'm missing?
> > >
> > > -Val
> > >
> >
>
Re: Timeout for ordered message
Posted by Valentin Kulichenko <va...@gmail.com>.
Yakov,
I was actually asking about the public API for messaging
(IgniteMessaging#sendOrdered
method). Here is the JavaDoc:
* The {@code timeout} parameter specifies how long an out-of-order message
will stay in a queue,
* waiting for messages that are ordered ahead of it to arrive. If timeout
expires, then all ordered
* messages that have not arrived before this message will be skipped. When
(and if) expired messages
* actually do arrive, they will be ignored.
I remember that we indeed had this scenario possible a while ago, but then
implementation of ordered messaging was reworked and 'out-of-order message'
can't happen anymore. Is this correct? If so, I think the timeout should be
removed from the API.
-Val
On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov <yz...@gridgain.com>
wrote:
> Val, timeout still makes sense for task sessions. It is possible that all
> jobs mapped to node have been completed, but node still receives
> attributes. Attributes are sent in ordered messages. It may happen so that
> node may start processing jobs for that task again and this way all the
> attributes will be available. If task timeout elapses then messages get
> cleared. Please let me know if you still have questions.
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com
> >:
>
> > Folks,
> >
> > Anyone knows what is the purpose of the timeout for
> > IgniteMessaging#sendOrdered method?
> >
> > void sendOrdered(@Nullable Object topic, Object msg, long timeout);
> >
> > It seems to me that in current implementation messages are always ordered
> > on communication level. I.e. if you send messages 1, 2 and 3, there is no
> > way to receive 3 before 2. The only difference between ordered and
> > unordered messages is that ordered are processed one after another in a
> > single thread, while unordered can be processed in parallel.
> >
> > Having said that, timeout for ordered messages doesn't make much sense to
> > me. Is there a scenario that I'm missing?
> >
> > -Val
> >
>
Re: Timeout for ordered message
Posted by Yakov Zhdanov <yz...@gridgain.com>.
Val, timeout still makes sense for task sessions. It is possible that all
jobs mapped to node have been completed, but node still receives
attributes. Attributes are sent in ordered messages. It may happen so that
node may start processing jobs for that task again and this way all the
attributes will be available. If task timeout elapses then messages get
cleared. Please let me know if you still have questions.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2017-01-06 1:02 GMT+03:00 Valentin Kulichenko <valentin.kulichenko@gmail.com
>:
> Folks,
>
> Anyone knows what is the purpose of the timeout for
> IgniteMessaging#sendOrdered method?
>
> void sendOrdered(@Nullable Object topic, Object msg, long timeout);
>
> It seems to me that in current implementation messages are always ordered
> on communication level. I.e. if you send messages 1, 2 and 3, there is no
> way to receive 3 before 2. The only difference between ordered and
> unordered messages is that ordered are processed one after another in a
> single thread, while unordered can be processed in parallel.
>
> Having said that, timeout for ordered messages doesn't make much sense to
> me. Is there a scenario that I'm missing?
>
> -Val
>