Channel API - onMessage blocking?

[Halm Reusser]

Hi,

when we use the channel api on the development server, polling is
used, this assures that all incoming messages are queued and onMessage
is called sequentially.

I'm wondering if on production, where long lived http connections are
used, the same assumption is correct?

In our case, we need to assure that onMessage is executed synchronous,
is that true or do we need to build a queue?

Thanks in advance!

[Chiguireitor]

Hi Halm, i'm currently building a queue to ensure sequential delivery (adding buffering too). I suggest you to do the same, because everytime you send a message, the connection needs to be restablished.

[Halm Reusser]

Hi Chiguireitor,

thanks.

On Jun 16, 3:53 pm, Chiguireitor <johnvillarzava...@gmail.com> wrote:
> Hi Halm, i'm currently building a queue to ensure sequential delivery
> (adding buffering too).

So, that means onMessage spawns a new thread? I.e. it is not assured
that the before onMessage call is completed?

> I suggest you to do the same, because everytime you
> send a message, the connection needs to be restablished.

Sorry, that I didn't understand, why the connection must be re-
established?