Re: [Tsp-devel] Flooding the BB msg queue

[Eric Noulard]

2007/6/20, Frederik Deweerdt <address@hidden>:
> Hello Eric,

Hi Fred,

> >
> > I'm not sure that sysV IPC guarantees that on msgsnd returns the
> > message has ALREADY been sent..
> Hm, I don't get it, I was expecting to get EAGAIN in errno:
>
> EAGAIN     The message can't be sent due to the msg_qbytes limit for
>            the queue and IPC_NOWAIT was specified in msgflg.
>
> What I want to know, is if the msg queue is full or not. If yes, I want
> to empty it to allow other clients to get their information.

I meant that:
1) Knowing if message queue is full is easy and you can rely on it.
2) Knowing if message has been delivered, enqueue, taken into account
   by the systems etc... when msgsend returns (with no error) is another issue.

If you only need 1) then it's OK.

> > Moreover I'm not sure that we should introduce such an assumption.
> > I may imagine networked implementation of message queue for which
> > "was really sent" is not a easy question to answer.
> > I would assume something more like "enqueued for sending".
> I can see the problem, however, I think that the BB master (the one
> sending sync), could use the fact that client n°3 lost its connection
> and that it can't be notified anymore.

BB msg queue was not meant to be "multi-client" in the current implementation.
but keep reading.

> >
> > >I'd like to rely on error retcodes to find out if a client is dead or
> > >not, and currently, this is not possible.
> >
> > I'm not sure it is the "good" way to ensure client liveness,
> > you may ask client to send you a ACK message on the same queue
> > (or another one).
> I didn't think of that one at first, it seems a bit fragile tought,
> because depending on timing issues, your queue could fill up a prevent
> other clients from notifying.

Yes it is fragile.
The fact is the BB msg queue was not meant to be multi_client.

> >
> > We should be able to silently ignore full BB message queue
> > because BB message queue was primarily thought as a
> > synchronization mean between user application using BB
> > and a bb_tsp_provider.
>
> I had a quick look, it looks like the case where there are multiple
> clients of the BB works because the BB is shadowed at first, isn't it?

It doesn't works.
It look as if it works, but in fact your several BB client take
the sync from one another, for a test:

launch bb_simu -s
then launch 1 bb_tsp_provider + 1 tsp client
works as usual

the
launch a seconf bb_tsp_provider on the same BB
then you will see your tsp client hogging because
the second bb_tsp_provider "steal"  synchro from the first one :(((

> But that means that we cannot get to modify the BB with multiple users
> of it?
>
> My use case is more or less like sync, but I use the PID of the client
> as mtype, so that I can tell several clients that value X vas
> modified. Otherwise, only the first one that gets the msg is notified.

That's perfectly true.

> If one subscriber suddenly dissapears, the queue fills up and no one ever
> gets the sync after a few messages.
>
> So I think that this might still be a "legitimate" use of the BB msg
> queues, what do you think?

The choice to make here is the following:

Should we keep BB message queue "as-is' for multiple subscriber or not?

1) If yes then you'll have to flush for dead client but it costs time
2) If no how should we handle this properly

> >
> > The application send "bb_simple_synchro_go"
> > and the provider "bb_simple_synchro_wait"
> > (look at the code for the message content).
> >
> > The application should run "as usual" even if the
> > bb_tsp_provider is not running thus not consuming
> > the synchro go messages.
> Then, it should ignore BB_NOK depending on errno?

No, it shouldn't even bother for the retcode value for bb_msg_snd.
In fact bb_msg_snd is of no USE for the user application.
This is the CURRENT usage,
your usage may need better retcode handling.

> > In the end I think you may change the retcode of bb_sng_msg
> > for a meaningfull one when the queue is full, it should not
> > bother current BB suer app.
> Do you refer to in-CVS implentations or wild BB out there?

I refer to every BB usage I am aware of, which of course may not
be complete.

> Obviously,
> if they check for BB_NOK and then abort, they'd need a rewrite...

Definitely True.


--
Erk