You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2008/07/21 11:23:25 UTC
Comet support on our NIO HTTP?
Folks
One of the things I am increasingly interested in is events and EDA,
and while Synapse already supports Atom, JMS, XMPP (tho not XMPP
pub/sub AFAIK), I think it might be interesting to think how you would
implement a Comet model
http://en.wikipedia.org/wiki/Comet_(programming) with Synapse.
It seems to me that our NIO HTTP model is very suited in one way
(async), but I guess we'd probably need to do a lot of work to support
handling more than one message per connection because its not clear to
me how you would associate the messages with the connection.
Thoughts?
Paul
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Comet support on our NIO HTTP?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2008-07-21 at 13:35 +0100, Paul Fremantle wrote:
> Maybe it isn't different. I'm not an expert on the HTTP transport.
>
> In general, a keep-alive is transparent to the Synapse message flow -
> it is effectively managed by the client and each request-response pair
> is logically separate. A comet connection logically supports both in
> and out messages in any order and something needs to indicate to the
> transport which existing connection this message is going to. For
> example, suppose you have 50 incoming connections, each of which is
> looking for different stock quotes based on a filter, something needs
> to decide which connections to send the MSFT quote down when it comes
> in. I guess logically speaking, we need a unique to-address for each
> open connection so that it can be addressed by a message.
>
> Paul
>
Paul et al
I have not studied Comet in details but it seems all it takes a stateful
connection manager. We already have one for HttpClient 4.0 but it is
based on classic (blocking) I/O. There are plans to start working on a
NIO connection manager at some point of time.
Oleg
> On Mon, Jul 21, 2008 at 1:24 PM, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
> > On the server-side, why is Comet different from a keep-alive connection
> > where we have to process multiple independent requests on the same socket
> > connection?
> >
> > Sanjiva.
> >
> > Paul Fremantle wrote:
> >>
> >> Folks
> >>
> >> One of the things I am increasingly interested in is events and EDA,
> >> and while Synapse already supports Atom, JMS, XMPP (tho not XMPP
> >> pub/sub AFAIK), I think it might be interesting to think how you would
> >> implement a Comet model
> >> http://en.wikipedia.org/wiki/Comet_(programming) with Synapse.
> >>
> >> It seems to me that our NIO HTTP model is very suited in one way
> >> (async), but I guess we'd probably need to do a lot of work to support
> >> handling more than one message per connection because its not clear to
> >> me how you would associate the messages with the connection.
> >>
> >> Thoughts?
> >>
> >> Paul
> >>
> >>
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > Blog: http://sanjiva.weerawarana.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> > For additional commands, e-mail: dev-help@synapse.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Comet support on our NIO HTTP?
Posted by Paul Fremantle <pz...@gmail.com>.
Maybe it isn't different. I'm not an expert on the HTTP transport.
In general, a keep-alive is transparent to the Synapse message flow -
it is effectively managed by the client and each request-response pair
is logically separate. A comet connection logically supports both in
and out messages in any order and something needs to indicate to the
transport which existing connection this message is going to. For
example, suppose you have 50 incoming connections, each of which is
looking for different stock quotes based on a filter, something needs
to decide which connections to send the MSFT quote down when it comes
in. I guess logically speaking, we need a unique to-address for each
open connection so that it can be addressed by a message.
Paul
On Mon, Jul 21, 2008 at 1:24 PM, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> On the server-side, why is Comet different from a keep-alive connection
> where we have to process multiple independent requests on the same socket
> connection?
>
> Sanjiva.
>
> Paul Fremantle wrote:
>>
>> Folks
>>
>> One of the things I am increasingly interested in is events and EDA,
>> and while Synapse already supports Atom, JMS, XMPP (tho not XMPP
>> pub/sub AFAIK), I think it might be interesting to think how you would
>> implement a Comet model
>> http://en.wikipedia.org/wiki/Comet_(programming) with Synapse.
>>
>> It seems to me that our NIO HTTP model is very suited in one way
>> (async), but I guess we'd probably need to do a lot of work to support
>> handling more than one message per connection because its not clear to
>> me how you would associate the messages with the connection.
>>
>> Thoughts?
>>
>> Paul
>>
>>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Comet support on our NIO HTTP?
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On the server-side, why is Comet different from a keep-alive connection
where we have to process multiple independent requests on the same socket
connection?
Sanjiva.
Paul Fremantle wrote:
> Folks
>
> One of the things I am increasingly interested in is events and EDA,
> and while Synapse already supports Atom, JMS, XMPP (tho not XMPP
> pub/sub AFAIK), I think it might be interesting to think how you would
> implement a Comet model
> http://en.wikipedia.org/wiki/Comet_(programming) with Synapse.
>
> It seems to me that our NIO HTTP model is very suited in one way
> (async), but I guess we'd probably need to do a lot of work to support
> handling more than one message per connection because its not clear to
> me how you would associate the messages with the connection.
>
> Thoughts?
>
> Paul
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org