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 <yzhda...@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.kuliche...@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 <yzhda...@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.kuliche...@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 <yzhda...@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.kuliche...@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 <
> > > yzhda...@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.kuliche...@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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
