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 2007/02/13 20:55:23 UTC
Re: asynchronous messaging question
Michele
We (the Synapse team) have written a pure non-blocking HTTP transport
for Axis2. Its currently in the Synapse repository, but we will check
it into the core Axis2 SVN when its stable.
However, I wanted to clear up the asynchronous model. This isn't a
clear area by any means!
The current Axis2 with Addressing is actually already asynchronous.
What happens is that if the replyTo address is a real HTTP URL
(useSeparateListener), then the client will start up a mini HTTP
server. The service will respond instantly with an HTTP 202 OK
(accepted message but not yet processed), and the HTTP connection will
be closed. When the response is ready, the server will open a new
connection to the client's HTTP server and pass the response over
that.
The reason we wrote the non-blocking transport is that we wanted to be
asynchronous even in the case where WS-Addressing ISN'T being used. In
other words, the client has an open socket to the server, but we
didn't want to block a thread waiting for the socket.
We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
client model, so we based our code on the Jakarta HTTPCore project
which also has NIO support.
BTW Another truly asynchronous protocol we support is SMTP.
Paul
On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> Hi all,
>
> the addressing module allows for asynchronous messaging. However the
> used transport mechanisms are synchronous (at least tcp and http). Since
> alternatives exist (e.g. [1, 2]), is there any future plan to take
> advantage of fully asynchronous computation?
>
>
> Thanks,
> Michele
>
>
> [1] http://mina.apache.org/index.html
> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: asynchronous messaging question
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Alek,
The value of the non-blocking approach here is not to support longer
asynchrony on the client side but rather simply more clients being
mediated thru Synapse.
Without this the # of messages that synapse can mediate simultaneously
is bound by the number of threads it can spawn. Clearly not acceptable.
Sanjiva.
On Tue, 2007-02-13 at 21:42 +0000, Paul Fremantle wrote:
> Alek
>
> I agree that the blocking socket doesn't work as reliably as WS-A.
> However, many clients still only support basic SOAP which is why we
> added the Non-Blocking approach to Synapse.
>
> Paul
>
> On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> > Paul Fremantle wrote:
> > > Michele
> > >
> > > We (the Synapse team) have written a pure non-blocking HTTP transport
> > > for Axis2. Its currently in the Synapse repository, but we will check
> > > it into the core Axis2 SVN when its stable.
> > >
> > > However, I wanted to clear up the asynchronous model. This isn't a
> > > clear area by any means!
> > >
> > > The current Axis2 with Addressing is actually already asynchronous.
> > > What happens is that if the replyTo address is a real HTTP URL
> > > (useSeparateListener), then the client will start up a mini HTTP
> > > server. The service will respond instantly with an HTTP 202 OK
> > > (accepted message but not yet processed), and the HTTP connection will
> > > be closed. When the response is ready, the server will open a new
> > > connection to the client's HTTP server and pass the response over
> > > that.
> > >
> > > The reason we wrote the non-blocking transport is that we wanted to be
> > > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > > other words, the client has an open socket to the server, but we
> > > didn't want to block a thread waiting for the socket.
> > hi Paul,
> >
> > but that puts very high burden on server and TCP stack (assuming that
> > you modified kernel to allow more than usual 1000 socket per process)
> > and it is not robust in case when client needs to wait for response
> > longer than few minutes (i have example applications that use WSA to
> > wait for response for hours or days).
> >
> > so what is the advantage of not using WSA?
> >
> >
> > >
> > > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > > client model, so we based our code on the Jakarta HTTPCore project
> > > which also has NIO support.
> > >
> > > BTW Another truly asynchronous protocol we support is SMTP.
> > SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> > history shows that seems to work very well ...
> >
> > thanks,
> >
> > alek
> > >
> > > Paul
> > >
> > > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > >> Hi all,
> > >>
> > >> the addressing module allows for asynchronous messaging. However the
> > >> used transport mechanisms are synchronous (at least tcp and http). Since
> > >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> > >> advantage of fully asynchronous computation?
> > >>
> > >>
> > >> Thanks,
> > >> Michele
> > >>
> > >>
> > >> [1] http://mina.apache.org/index.html
> > >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-user-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: asynchronous messaging question
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Alek,
The value of the non-blocking approach here is not to support longer
asynchrony on the client side but rather simply more clients being
mediated thru Synapse.
Without this the # of messages that synapse can mediate simultaneously
is bound by the number of threads it can spawn. Clearly not acceptable.
Sanjiva.
On Tue, 2007-02-13 at 21:42 +0000, Paul Fremantle wrote:
> Alek
>
> I agree that the blocking socket doesn't work as reliably as WS-A.
> However, many clients still only support basic SOAP which is why we
> added the Non-Blocking approach to Synapse.
>
> Paul
>
> On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> > Paul Fremantle wrote:
> > > Michele
> > >
> > > We (the Synapse team) have written a pure non-blocking HTTP transport
> > > for Axis2. Its currently in the Synapse repository, but we will check
> > > it into the core Axis2 SVN when its stable.
> > >
> > > However, I wanted to clear up the asynchronous model. This isn't a
> > > clear area by any means!
> > >
> > > The current Axis2 with Addressing is actually already asynchronous.
> > > What happens is that if the replyTo address is a real HTTP URL
> > > (useSeparateListener), then the client will start up a mini HTTP
> > > server. The service will respond instantly with an HTTP 202 OK
> > > (accepted message but not yet processed), and the HTTP connection will
> > > be closed. When the response is ready, the server will open a new
> > > connection to the client's HTTP server and pass the response over
> > > that.
> > >
> > > The reason we wrote the non-blocking transport is that we wanted to be
> > > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > > other words, the client has an open socket to the server, but we
> > > didn't want to block a thread waiting for the socket.
> > hi Paul,
> >
> > but that puts very high burden on server and TCP stack (assuming that
> > you modified kernel to allow more than usual 1000 socket per process)
> > and it is not robust in case when client needs to wait for response
> > longer than few minutes (i have example applications that use WSA to
> > wait for response for hours or days).
> >
> > so what is the advantage of not using WSA?
> >
> >
> > >
> > > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > > client model, so we based our code on the Jakarta HTTPCore project
> > > which also has NIO support.
> > >
> > > BTW Another truly asynchronous protocol we support is SMTP.
> > SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> > history shows that seems to work very well ...
> >
> > thanks,
> >
> > alek
> > >
> > > Paul
> > >
> > > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > >> Hi all,
> > >>
> > >> the addressing module allows for asynchronous messaging. However the
> > >> used transport mechanisms are synchronous (at least tcp and http). Since
> > >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> > >> advantage of fully asynchronous computation?
> > >>
> > >>
> > >> Thanks,
> > >> Michele
> > >>
> > >>
> > >> [1] http://mina.apache.org/index.html
> > >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-user-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Paul Fremantle <pz...@gmail.com>.
Alek
I agree that the blocking socket doesn't work as reliably as WS-A.
However, many clients still only support basic SOAP which is why we
added the Non-Blocking approach to Synapse.
Paul
On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Paul Fremantle wrote:
> > Michele
> >
> > We (the Synapse team) have written a pure non-blocking HTTP transport
> > for Axis2. Its currently in the Synapse repository, but we will check
> > it into the core Axis2 SVN when its stable.
> >
> > However, I wanted to clear up the asynchronous model. This isn't a
> > clear area by any means!
> >
> > The current Axis2 with Addressing is actually already asynchronous.
> > What happens is that if the replyTo address is a real HTTP URL
> > (useSeparateListener), then the client will start up a mini HTTP
> > server. The service will respond instantly with an HTTP 202 OK
> > (accepted message but not yet processed), and the HTTP connection will
> > be closed. When the response is ready, the server will open a new
> > connection to the client's HTTP server and pass the response over
> > that.
> >
> > The reason we wrote the non-blocking transport is that we wanted to be
> > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > other words, the client has an open socket to the server, but we
> > didn't want to block a thread waiting for the socket.
> hi Paul,
>
> but that puts very high burden on server and TCP stack (assuming that
> you modified kernel to allow more than usual 1000 socket per process)
> and it is not robust in case when client needs to wait for response
> longer than few minutes (i have example applications that use WSA to
> wait for response for hours or days).
>
> so what is the advantage of not using WSA?
>
>
> >
> > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > client model, so we based our code on the Jakarta HTTPCore project
> > which also has NIO support.
> >
> > BTW Another truly asynchronous protocol we support is SMTP.
> SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> history shows that seems to work very well ...
>
> thanks,
>
> alek
> >
> > Paul
> >
> > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> >> Hi all,
> >>
> >> the addressing module allows for asynchronous messaging. However the
> >> used transport mechanisms are synchronous (at least tcp and http). Since
> >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> >> advantage of fully asynchronous computation?
> >>
> >>
> >> Thanks,
> >> Michele
> >>
> >>
> >> [1] http://mina.apache.org/index.html
> >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Paul Fremantle <pz...@gmail.com>.
Alek
I agree that the blocking socket doesn't work as reliably as WS-A.
However, many clients still only support basic SOAP which is why we
added the Non-Blocking approach to Synapse.
Paul
On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Paul Fremantle wrote:
> > Michele
> >
> > We (the Synapse team) have written a pure non-blocking HTTP transport
> > for Axis2. Its currently in the Synapse repository, but we will check
> > it into the core Axis2 SVN when its stable.
> >
> > However, I wanted to clear up the asynchronous model. This isn't a
> > clear area by any means!
> >
> > The current Axis2 with Addressing is actually already asynchronous.
> > What happens is that if the replyTo address is a real HTTP URL
> > (useSeparateListener), then the client will start up a mini HTTP
> > server. The service will respond instantly with an HTTP 202 OK
> > (accepted message but not yet processed), and the HTTP connection will
> > be closed. When the response is ready, the server will open a new
> > connection to the client's HTTP server and pass the response over
> > that.
> >
> > The reason we wrote the non-blocking transport is that we wanted to be
> > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > other words, the client has an open socket to the server, but we
> > didn't want to block a thread waiting for the socket.
> hi Paul,
>
> but that puts very high burden on server and TCP stack (assuming that
> you modified kernel to allow more than usual 1000 socket per process)
> and it is not robust in case when client needs to wait for response
> longer than few minutes (i have example applications that use WSA to
> wait for response for hours or days).
>
> so what is the advantage of not using WSA?
>
>
> >
> > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > client model, so we based our code on the Jakarta HTTPCore project
> > which also has NIO support.
> >
> > BTW Another truly asynchronous protocol we support is SMTP.
> SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> history shows that seems to work very well ...
>
> thanks,
>
> alek
> >
> > Paul
> >
> > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> >> Hi all,
> >>
> >> the addressing module allows for asynchronous messaging. However the
> >> used transport mechanisms are synchronous (at least tcp and http). Since
> >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> >> advantage of fully asynchronous computation?
> >>
> >>
> >> Thanks,
> >> Michele
> >>
> >>
> >> [1] http://mina.apache.org/index.html
> >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: asynchronous messaging question
Posted by Paul Fremantle <pz...@gmail.com>.
Angel
No, the WSA approach doesn't work through firewalls with HTTP. We just
published a spec as part of the WSRM initiative that solves this
problem (WS-MakeConnection).
However, other protocols like SMTP and Jabber solve the firewall problem.
Paul
On 2/13/07, Angel Todorov <at...@gmail.com> wrote:
> Hi Paul,
>
> What about firewall issues and WS clients staying behind NAT ? Is this
> possible with the current Axis2 WS-Addressing impl, if a client brings
> up a HTTP server and the "real" server connects back to it ? Thanks.
>
> Best,
> Angel
>
> On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> > Paul Fremantle wrote:
> > > Michele
> > >
> > > We (the Synapse team) have written a pure non-blocking HTTP transport
> > > for Axis2. Its currently in the Synapse repository, but we will check
> > > it into the core Axis2 SVN when its stable.
> > >
> > > However, I wanted to clear up the asynchronous model. This isn't a
> > > clear area by any means!
> > >
> > > The current Axis2 with Addressing is actually already asynchronous.
> > > What happens is that if the replyTo address is a real HTTP URL
> > > (useSeparateListener), then the client will start up a mini HTTP
> > > server. The service will respond instantly with an HTTP 202 OK
> > > (accepted message but not yet processed), and the HTTP connection will
> > > be closed. When the response is ready, the server will open a new
> > > connection to the client's HTTP server and pass the response over
> > > that.
> > >
> > > The reason we wrote the non-blocking transport is that we wanted to be
> > > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > > other words, the client has an open socket to the server, but we
> > > didn't want to block a thread waiting for the socket.
> > hi Paul,
> >
> > but that puts very high burden on server and TCP stack (assuming that
> > you modified kernel to allow more than usual 1000 socket per process)
> > and it is not robust in case when client needs to wait for response
> > longer than few minutes (i have example applications that use WSA to
> > wait for response for hours or days).
> >
> > so what is the advantage of not using WSA?
> >
> >
> > >
> > > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > > client model, so we based our code on the Jakarta HTTPCore project
> > > which also has NIO support.
> > >
> > > BTW Another truly asynchronous protocol we support is SMTP.
> > SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> > history shows that seems to work very well ...
> >
> > thanks,
> >
> > alek
> > >
> > > Paul
> > >
> > > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > >> Hi all,
> > >>
> > >> the addressing module allows for asynchronous messaging. However the
> > >> used transport mechanisms are synchronous (at least tcp and http). Since
> > >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> > >> advantage of fully asynchronous computation?
> > >>
> > >>
> > >> Thanks,
> > >> Michele
> > >>
> > >>
> > >> [1] http://mina.apache.org/index.html
> > >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-user-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Angel Todorov <at...@gmail.com>.
Hi Paul,
What about firewall issues and WS clients staying behind NAT ? Is this
possible with the current Axis2 WS-Addressing impl, if a client brings
up a HTTP server and the "real" server connects back to it ? Thanks.
Best,
Angel
On 2/13/07, Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Paul Fremantle wrote:
> > Michele
> >
> > We (the Synapse team) have written a pure non-blocking HTTP transport
> > for Axis2. Its currently in the Synapse repository, but we will check
> > it into the core Axis2 SVN when its stable.
> >
> > However, I wanted to clear up the asynchronous model. This isn't a
> > clear area by any means!
> >
> > The current Axis2 with Addressing is actually already asynchronous.
> > What happens is that if the replyTo address is a real HTTP URL
> > (useSeparateListener), then the client will start up a mini HTTP
> > server. The service will respond instantly with an HTTP 202 OK
> > (accepted message but not yet processed), and the HTTP connection will
> > be closed. When the response is ready, the server will open a new
> > connection to the client's HTTP server and pass the response over
> > that.
> >
> > The reason we wrote the non-blocking transport is that we wanted to be
> > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > other words, the client has an open socket to the server, but we
> > didn't want to block a thread waiting for the socket.
> hi Paul,
>
> but that puts very high burden on server and TCP stack (assuming that
> you modified kernel to allow more than usual 1000 socket per process)
> and it is not robust in case when client needs to wait for response
> longer than few minutes (i have example applications that use WSA to
> wait for response for hours or days).
>
> so what is the advantage of not using WSA?
>
>
> >
> > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > client model, so we based our code on the Jakarta HTTPCore project
> > which also has NIO support.
> >
> > BTW Another truly asynchronous protocol we support is SMTP.
> SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
> history shows that seems to work very well ...
>
> thanks,
>
> alek
> >
> > Paul
> >
> > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> >> Hi all,
> >>
> >> the addressing module allows for asynchronous messaging. However the
> >> used transport mechanisms are synchronous (at least tcp and http). Since
> >> alternatives exist (e.g. [1, 2]), is there any future plan to take
> >> advantage of fully asynchronous computation?
> >>
> >>
> >> Thanks,
> >> Michele
> >>
> >>
> >> [1] http://mina.apache.org/index.html
> >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Paul Fremantle wrote:
> Michele
>
> We (the Synapse team) have written a pure non-blocking HTTP transport
> for Axis2. Its currently in the Synapse repository, but we will check
> it into the core Axis2 SVN when its stable.
>
> However, I wanted to clear up the asynchronous model. This isn't a
> clear area by any means!
>
> The current Axis2 with Addressing is actually already asynchronous.
> What happens is that if the replyTo address is a real HTTP URL
> (useSeparateListener), then the client will start up a mini HTTP
> server. The service will respond instantly with an HTTP 202 OK
> (accepted message but not yet processed), and the HTTP connection will
> be closed. When the response is ready, the server will open a new
> connection to the client's HTTP server and pass the response over
> that.
>
> The reason we wrote the non-blocking transport is that we wanted to be
> asynchronous even in the case where WS-Addressing ISN'T being used. In
> other words, the client has an open socket to the server, but we
> didn't want to block a thread waiting for the socket.
hi Paul,
but that puts very high burden on server and TCP stack (assuming that
you modified kernel to allow more than usual 1000 socket per process)
and it is not robust in case when client needs to wait for response
longer than few minutes (i have example applications that use WSA to
wait for response for hours or days).
so what is the advantage of not using WSA?
>
> We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> client model, so we based our code on the Jakarta HTTPCore project
> which also has NIO support.
>
> BTW Another truly asynchronous protocol we support is SMTP.
SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
history shows that seems to work very well ...
thanks,
alek
>
> Paul
>
> On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
>> Hi all,
>>
>> the addressing module allows for asynchronous messaging. However the
>> used transport mechanisms are synchronous (at least tcp and http). Since
>> alternatives exist (e.g. [1, 2]), is there any future plan to take
>> advantage of fully asynchronous computation?
>>
>>
>> Thanks,
>> Michele
>>
>>
>> [1] http://mina.apache.org/index.html
>> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: [Axis2] Axis classloading issue in tomcat war deployment
Posted by Sathija Pavuluri <sp...@EmprisaNetworks.com>.
Deepal,
I am using tomcat 5.5.20.
It works for me when I drop my war file to /webapps and server.xml setting is:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
This unpacks the war file and everything works fine.
However, when I drop my war file to /webapps and change the above setting to
<Host name="localhost" appBase="webapps"
unpackWARs="false" autoDeploy="false"
xmlValidation="false" xmlNamespaceAware="false">
I get the axis startup error described below.
I suspect you were unpacking the war on your test run.
Would you try with unpackWARs="false" and make sure you only have the .war file in your /webapps and not the unpacked
archvie.
I have been reading up on this issue and found a thread on tomcat user list that said this about running apps without
unpacking the war:
****************************************************************************
One thing to watch out for when running an app directly from a .war
file is that if the application is trying to do any File IO where it
tries to load resources existing within the WAR structure, it won't
work if the .war is not expanded into a directory. I've noticed
various frameworks that ignore this and continue to use File IO.
These apps *will* break. See if you are getting any stack traces in
Tomcat's log files.
The webapp itself has to be written so that it can work inside a WAR.
Most commonly, that means using ServletContext.getResource() or
ServletContext.getResourceAsStream() instead of file i/o in order to read
webapp resources.
****************************************************************************
If this is true, I suspect axis uses file i/o to load modules, hence the error below.
Is this something axis can support if doesnt already?
Thanks,
Sathija.
> I test with tomcat 5.0 and it worked for me, so what is the Tomcat
> version are you using ?
>
> Thanks
> Deepal
>
> Sathija Pavuluri wrote:
>
>>Hi,
>>
>>When I startup tomcat on my development box with my webapp containing axis repo, everything works fine.
>>My app's WEB-INF contains services/Test.aar
>> modules/addressing.mar
>> conf/axis2.xml
>>When I war the same application and deploy on a test box, tomcat log shows this error during startup of axis servlet.
>>Happens both on Linux and Windows environments.
>>
>>Looks like there are some class loading issues when the webapp is deployed as a war file.
>>
>>Are there any known issues here? I am using Axis2 1.1.1.
>>
>>Below is the snippet from tomcat's log that shows axis startup error.
>>
>>Thanks,
>>Sathija.
>>
>>********************************************************************
>>
>>SEVERE: Servlet /test-app threw load() exception
>>org.apache.axis2.AxisFault: The system is attempting to engage a module
>>that is not available: addressing
>> at
>>org.apache.axis2.engine.AxisConfiguration.engageModule(AxisConfiguration.java:394)
>> at
>>org.apache.axis2.deployment.DeploymentEngine.engageModules(DeploymentEngine.java:663)
>> at
>>org.apache.axis2.deployment.WarBasedAxisConfigurator.engageGlobalModules(WarBasedAxisConfigurator.java:269)
>> at
>>org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:69)
>> at
>>org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:385)
>> at
>>org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:335)
>> at
>>org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
>> at
>>org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
>> at
>>org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
>> at
>>org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>>
>>
>
> --
> Thanks,
> Deepal
> ................................................................
> "The highest tower is built one brick at a time"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] Axis classloading issue in tomcat war deployment
Posted by Deepal Jayasinghe <de...@opensource.lk>.
I test with tomcat 5.0 and it worked for me, so what is the Tomcat
version are you using ?
Thanks
Deepal
Sathija Pavuluri wrote:
>Hi,
>
>When I startup tomcat on my development box with my webapp containing axis repo, everything works fine.
>My app's WEB-INF contains services/Test.aar
> modules/addressing.mar
> conf/axis2.xml
>When I war the same application and deploy on a test box, tomcat log shows this error during startup of axis servlet.
>Happens both on Linux and Windows environments.
>
>Looks like there are some class loading issues when the webapp is deployed as a war file.
>
>Are there any known issues here? I am using Axis2 1.1.1.
>
>Below is the snippet from tomcat's log that shows axis startup error.
>
>Thanks,
>Sathija.
>
>********************************************************************
>
>SEVERE: Servlet /test-app threw load() exception
>org.apache.axis2.AxisFault: The system is attempting to engage a module
>that is not available: addressing
> at
>org.apache.axis2.engine.AxisConfiguration.engageModule(AxisConfiguration.java:394)
> at
>org.apache.axis2.deployment.DeploymentEngine.engageModules(DeploymentEngine.java:663)
> at
>org.apache.axis2.deployment.WarBasedAxisConfigurator.engageGlobalModules(WarBasedAxisConfigurator.java:269)
> at
>org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:69)
> at
>org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:385)
> at
>org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:335)
> at
>org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
> at
>org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
> at
>org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
> at
>org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
[Axis2] Axis classloading issue in tomcat war deployment
Posted by Sathija Pavuluri <sp...@EmprisaNetworks.com>.
Hi,
When I startup tomcat on my development box with my webapp containing axis repo, everything works fine.
My app's WEB-INF contains services/Test.aar
modules/addressing.mar
conf/axis2.xml
When I war the same application and deploy on a test box, tomcat log shows this error during startup of axis servlet.
Happens both on Linux and Windows environments.
Looks like there are some class loading issues when the webapp is deployed as a war file.
Are there any known issues here? I am using Axis2 1.1.1.
Below is the snippet from tomcat's log that shows axis startup error.
Thanks,
Sathija.
********************************************************************
SEVERE: Servlet /test-app threw load() exception
org.apache.axis2.AxisFault: The system is attempting to engage a module
that is not available: addressing
at
org.apache.axis2.engine.AxisConfiguration.engageModule(AxisConfiguration.java:394)
at
org.apache.axis2.deployment.DeploymentEngine.engageModules(DeploymentEngine.java:663)
at
org.apache.axis2.deployment.WarBasedAxisConfigurator.engageGlobalModules(WarBasedAxisConfigurator.java:269)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:69)
at
org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:385)
at
org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:335)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Paul Fremantle <pz...@gmail.com>.
Michele
AsyncWeb has some HTTP client code but its in scratch and hasn't been
touched in a while.
MINA supports anything you want, but you have to write the HTTP
handling code. That is effectively what AsyncWeb is - HTTP on top of
MINA.
The Jakarta HTTPComponents HTTPCore NIO extensions
(http://jakarta.apache.org/httpcomponents/index.html) are basically an
equivalent to asyncweb built directly on top of the Java NIO library.
They support both client and server side which we needed in Synapse.
They also can be layered on top on MINA if there is a need to.
Paul
On 2/14/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> Paul,
>
> what do you mean when you say "AsyncWeb doesn't support a client model"?
> And what about Mina?
>
>
> Thanks,
> Michele
>
> On Tue, 2007-02-13 at 19:55 +0000, Paul Fremantle wrote:
> > Michele
> >
> > We (the Synapse team) have written a pure non-blocking HTTP transport
> > for Axis2. Its currently in the Synapse repository, but we will check
> > it into the core Axis2 SVN when its stable.
> >
> > However, I wanted to clear up the asynchronous model. This isn't a
> > clear area by any means!
> >
> > The current Axis2 with Addressing is actually already asynchronous.
> > What happens is that if the replyTo address is a real HTTP URL
> > (useSeparateListener), then the client will start up a mini HTTP
> > server. The service will respond instantly with an HTTP 202 OK
> > (accepted message but not yet processed), and the HTTP connection will
> > be closed. When the response is ready, the server will open a new
> > connection to the client's HTTP server and pass the response over
> > that.
> >
> > The reason we wrote the non-blocking transport is that we wanted to be
> > asynchronous even in the case where WS-Addressing ISN'T being used. In
> > other words, the client has an open socket to the server, but we
> > didn't want to block a thread waiting for the socket.
> >
> > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> > client model, so we based our code on the Jakarta HTTPCore project
> > which also has NIO support.
> >
> > BTW Another truly asynchronous protocol we support is SMTP.
> >
> > Paul
> >
> > On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > > Hi all,
> > >
> > > the addressing module allows for asynchronous messaging. However the
> > > used transport mechanisms are synchronous (at least tcp and http). Since
> > > alternatives exist (e.g. [1, 2]), is there any future plan to take
> > > advantage of fully asynchronous computation?
> > >
> > >
> > > Thanks,
> > > Michele
> > >
> > >
> > > [1] http://mina.apache.org/index.html
> > > [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Paul,
what do you mean when you say "AsyncWeb doesn't support a client model"?
And what about Mina?
Thanks,
Michele
On Tue, 2007-02-13 at 19:55 +0000, Paul Fremantle wrote:
> Michele
>
> We (the Synapse team) have written a pure non-blocking HTTP transport
> for Axis2. Its currently in the Synapse repository, but we will check
> it into the core Axis2 SVN when its stable.
>
> However, I wanted to clear up the asynchronous model. This isn't a
> clear area by any means!
>
> The current Axis2 with Addressing is actually already asynchronous.
> What happens is that if the replyTo address is a real HTTP URL
> (useSeparateListener), then the client will start up a mini HTTP
> server. The service will respond instantly with an HTTP 202 OK
> (accepted message but not yet processed), and the HTTP connection will
> be closed. When the response is ready, the server will open a new
> connection to the client's HTTP server and pass the response over
> that.
>
> The reason we wrote the non-blocking transport is that we wanted to be
> asynchronous even in the case where WS-Addressing ISN'T being used. In
> other words, the client has an open socket to the server, but we
> didn't want to block a thread waiting for the socket.
>
> We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> client model, so we based our code on the Jakarta HTTPCore project
> which also has NIO support.
>
> BTW Another truly asynchronous protocol we support is SMTP.
>
> Paul
>
> On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
> > Hi all,
> >
> > the addressing module allows for asynchronous messaging. However the
> > used transport mechanisms are synchronous (at least tcp and http). Since
> > alternatives exist (e.g. [1, 2]), is there any future plan to take
> > advantage of fully asynchronous computation?
> >
> >
> > Thanks,
> > Michele
> >
> >
> > [1] http://mina.apache.org/index.html
> > [2] http://docs.safehaus.org/display/ASYNCWEB/Home
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: asynchronous messaging question
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Paul Fremantle wrote:
> Michele
>
> We (the Synapse team) have written a pure non-blocking HTTP transport
> for Axis2. Its currently in the Synapse repository, but we will check
> it into the core Axis2 SVN when its stable.
>
> However, I wanted to clear up the asynchronous model. This isn't a
> clear area by any means!
>
> The current Axis2 with Addressing is actually already asynchronous.
> What happens is that if the replyTo address is a real HTTP URL
> (useSeparateListener), then the client will start up a mini HTTP
> server. The service will respond instantly with an HTTP 202 OK
> (accepted message but not yet processed), and the HTTP connection will
> be closed. When the response is ready, the server will open a new
> connection to the client's HTTP server and pass the response over
> that.
>
> The reason we wrote the non-blocking transport is that we wanted to be
> asynchronous even in the case where WS-Addressing ISN'T being used. In
> other words, the client has an open socket to the server, but we
> didn't want to block a thread waiting for the socket.
hi Paul,
but that puts very high burden on server and TCP stack (assuming that
you modified kernel to allow more than usual 1000 socket per process)
and it is not robust in case when client needs to wait for response
longer than few minutes (i have example applications that use WSA to
wait for response for hours or days).
so what is the advantage of not using WSA?
>
> We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a
> client model, so we based our code on the Jakarta HTTPCore project
> which also has NIO support.
>
> BTW Another truly asynchronous protocol we support is SMTP.
SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as
history shows that seems to work very well ...
thanks,
alek
>
> Paul
>
> On 2/13/07, Michele Mazzucco <Mi...@ncl.ac.uk> wrote:
>> Hi all,
>>
>> the addressing module allows for asynchronous messaging. However the
>> used transport mechanisms are synchronous (at least tcp and http). Since
>> alternatives exist (e.g. [1, 2]), is there any future plan to take
>> advantage of fully asynchronous computation?
>>
>>
>> Thanks,
>> Michele
>>
>>
>> [1] http://mina.apache.org/index.html
>> [2] http://docs.safehaus.org/display/ASYNCWEB/Home
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org