Jaliya
Sandesha already takes care of the pausing and acknowledgement. So that
is no problem.
As regards how Axis2 should handle the queuing of incoming requests,
ideally we should have a TransportIn that supports NIO or AIO. These
allow the listener to break the link between a thread and a socket and
thus have a pool of threads handling multiple sockets.
Paul
Jaliya Ekanayake wrote:
Hi Paul,
Please see my comments below.
Thanks,
Jaliya
----- Original Message ----- From: "Paul Fremantle" <[EMAIL PROTECTED]>
To: "Jaliya Ekanayake" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, May 05, 2006 10:21 AM
Subject: Re: WSRM handling
Jaliya
I'm not clear I understand. In the case that the Axis server pauses a
message no thread should be used.
I might have not expressed it correctly, this is what I have in mind;
Pausing does not cause any threading issue, however the handler which
call pause should keep track of the messages it has been paused. (e.g.
in RM case we need to send the an ack after the Acknowledgement
Interval (we have to either wait or have to incorporate a thread to
do that)
We could decouple the input of messages from the processing (that
model is called SEDA http://www.eecs.harvard.edu/~mdw/proj/seda/).
This is what I had in my mind. If you see the Figure 6 of article
http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf that is what I
had in my mind and I think we should start synapse as the EventHandler
in the figure.
However, studies have
shown that the overhead of thread switching is not always valuable.
If the Axis2 front-end is being saturated the first aim is to fix that.
Queueing can be a good model but shouldn't be essential in this model
- the Axis2 front-end should gracefully cope with many thousands of
requests and should be able to "queue" at the TCP/IP socket level.
Could not figure out a way to do this in a container based model.
Could you please explain a bit about it?
Paul
Jaliya Ekanayake wrote:
Hi Paul,
Here are some of my thoughts about this.
When we support RM from Synapse IMHO we need to support all the
three scenarios. It should have the full capabilities of an RM
Endpoint if we decided to support RM.
The major hurdle that I find in the architecture is the lack of
Queuing. It is true that Axis2 can pause the messages but there
should be some thread keeping track of this paused message and since
we are inside a container we always have the limitation from the
container's thread models. I tested this scenario and found that it
quickly exhaust the container's thread pool.
Scalability requirement of synapse is very high and we should go
for a model where the incoming messages does not cause limitations
to the performance. IMHO a standalone server (Standalone Synapse
Server) with front end queue will provide this capability and then
we can easily handle these QoSs. I even tested this scenario and
found that it does not load the container in the case of
Asynchronous Invocations. (I used Axis servlet just to inject
messages to a broker(Naradabroker http://www.naradabrokering.org/)
and Synapse "pulls" the messages from a Queue instead of getting
invoked.)
Any thoughts?
Thanks,
Jaliya
----- Original Message -----
*From:* Paul Fremantle <mailto:[EMAIL PROTECTED]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Friday, May 05, 2006 7:56 AM
*Subject:* WSRM handling
I'd like to start a discussion on handling WSRM in Synapse.
There are three aspects:
1. passthrough. In this model the sequence is from one endpoint to
the other, and Synapse doesn't really get involved.
2. Synapse as an RM client. The message comes into Synapse, maybe
over JMS or SMTP. We send it on with a sequence. Synapse is acting
as an RM client (probably two-way).
3. Synapse is acting as an RM server and passing messages on
without RM, perhaps to a "pre-RM" SOAP server, or via JMS.
1 isn't very interesting to us, tho we could do some special
logging.
2 should be fairly straightforward. We need to be able to
configure some aspects of the RM infrastructure - timeouts, the
assignment of messages to sequences etc. I will propose a config
model and syntax for this.
3 is a little tricky. The problem comes with "in-order" delivery.
If this is enabled then synapse may need to hold up further
processing of this message until earlier messages have been
delivered. Sandesha can take care of the "holding up", but we have
no way currently of pausing a mediator or re-injecting a message
partway through a mediator chain.
There are a few solutions to this I can think of:
A) Don't support inorder delivery - at least to start with. I
think this might be a worthwhile first step, but it isn't a good
long term solution as in-order is one of the main requirements
people have for RM.
B) Add pausing or re-injection into Synapse. This would be some
re-architecture. My main issue with this is that this is already
built into Axis2 so I'm not keen on re-building it in Synapse as
well if we can re-use the Axis2 capability instead.
C) This is a limited proposal but might be a reasonable model to
start with. The idea is to split processing into two halves. The
first half happens before RM "delivery" (i.e. before the inorder
constraint is applied). The second half takes place after
delivery. A simple syntax to handle this might look like:
<sequence>
<reliableTerminate> <!-- i.e. we are terminating the RM
connection in Synapse and passing on without RM -->
<pre-delivery>
mediators here
</pre-delivery>
<deliver/>
</reliableTerminate>
<mediator...> Any mediators here get called post delivery </med>
</sequence>
Paul
-- Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
"Oxygenating the Web Service Platform", www.wso2.com
<http://www.wso2.com>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
