You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Saminda Abeyruwan <sa...@gmail.com> on 2006/02/02 07:32:55 UTC
Proposal to keep states
Hi Devs,
*Problem* : Synapse needs a way to keep track of status of the incoming
message.
*Use case*: Assume a message comes (IN-Path) to Synapse and it is subjected
to few rules such as route to the destination1, once the response returns to
Synapse (if), again the message process through Synapse and hit another rule
to say route the message destination2. Once the response return (hopfully)
we need to send THIS processed response message again to to the initiator of
the original message (the Client).
Now during the above process we "new" SynaspeMessages and MessageContext in
Synapse, thus, this will restrain the ability of keeping the state of THIS
message.
As there is no such mechanism involved, there is no way Synapse to know
whether to trigger transport level details of Axis2 such as choosing between
200 OK and 202 OK.
*Proposal*
At present there is only ONE SynapseEnvironment available for every message
that is coming into Synapse. (This is analogues to Axis2's
ConfigurationContext)
According to the architecture <send/> will create a new SynapseMessage when
the response comes to a outbound message. So it it obvious that <send/> is
the last "Mediator" that should be in the mediator chain, before newing
another SynapseMessage to inject the response back into Synapse. This is
equivalent of treating this message as a fresh message entering into
Synapse. yet, this is the response to the original me
So, what we need per IN-Message is another level of abstraction that does
not change with newing SynapseMessage. Let's Call this MediationContext.
So when a message enters into Synapse there is only one MediationContext
exist for all of this message mutations until the return comes back to
SynapseMessageReceiver, to select between 200/202 OK.
So this MediatonContext can be used to keep state across mediators for a
given message.
Please see Figure1.
Please be kind enough to express your consensus on prior.
Thank you
Saminda
Re: Proposal to keep states
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi,
MediationContext is an internal implementation of Synapse, mainly focused on
selection of Axis2 transports when the message leaves Synapse.
If you look at SynapseMessageReceiver, when the message leaves Synapse it
only switch Axis2's POST with 200OK. Now if we want to switch to POST with
202OK , there is no way to do it.
Ex:
Lets assume a chain of mediators exist for a given message. as
<log/>
<regex message-address="to" pattern="news">
<xpath expr="some_expression">
<header to="http://cnn.com"/><send/></xpath></regex>
Once response comes to Synapse from cnn, we keep a state
"sm.setResponse(true)";
and create a new SynapseMessage and inject this into Synapse to more
processing.
At this point SynapseMessage keeps this simple state and when the Java
return comes back to SynapseMessageReciever, this should select the Axis2's
proper transport. But sm.isResponse(); is not enough for this task.
This is where MediationContext comes into play. MediationContext is only per
message and it keeps state changes for that message. {example selection of
http status 200/202OK properly}. Thus, SynapseMessage doesnot need to keep
separate states.
We can keep simple states with Message's Addressing headers. But do our
engine really need to depend on Addressing.
Please be kind enough to response on prior.
Thank you
Saminda
On 2/4/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
> Hi All,
>
> These days I am working on a message bridge that connect two JMS domains.
> So from that experience, I also believe that we should not keep the state
> inside the synapse for messages. This will bind us to use a single synapse
> instance for related messages and we will not be able to handle them using
> several synapse instances.( may be connected through some message queue)
>
> Thanks,
> - Jaliya
>
> ----- Original Message -----
> *From:* Paul Fremantle <pz...@gmail.com>
> *To:* synapse-dev@ws.apache.org
> *Sent:* Thursday, February 02, 2006 7:59 AM
> *Subject:* Re: Proposal to keep states
>
> Saminda
>
> I am very against us doing this.
>
> The aim of Synapse is to be widely deployed and clustered. This design
> assumes that the messages come back to a single synapse server and also that
> the server has not failed in the meantime.
>
> There are two solutions to this problem. The first solution is to use the
> WS-Addressing Reference parameters to include as much information as
> required in the message itself.
>
> The second solution is to use a process (BPEL) server.
>
> I strongly support us keeping Synapse stateless for very high performance,
> clustering and failover.
>
> Paul
>
> On 2/2/06, Saminda Abeyruwan < samindaa@gmail.com> wrote:
> >
> > Hi Devs,
> >
> > *Problem* : Synapse needs a way to keep track of status of the incoming
> > message.
> >
> > *Use case*: Assume a message comes (IN-Path) to Synapse and it is
> > subjected to few rules such as route to the destination1, once the response
> > returns to Synapse (if), again the message process through Synapse and hit
> > another rule to say route the message destination2. Once the response return
> > (hopfully) we need to send THIS processed response message again to to the
> > initiator of the original message (the Client).
> >
> > Now during the above process we "new" SynaspeMessages and MessageContext
> > in Synapse, thus, this will restrain the ability of keeping the state of
> > THIS message.
> >
> > As there is no such mechanism involved, there is no way Synapse to know
> > whether to trigger transport level details of Axis2 such as choosing between
> > 200 OK and 202 OK.
> >
> > *Proposal*
> >
> > At present there is only ONE SynapseEnvironment available for every
> > message that is coming into Synapse. (This is analogues to Axis2's
> > ConfigurationContext)
> >
> > According to the architecture <send/> will create a new SynapseMessage
> > when the response comes to a outbound message. So it it obvious that <send/>
> > is the last "Mediator" that should be in the mediator chain, before newing
> > another SynapseMessage to inject the response back into Synapse. This is
> > equivalent of treating this message as a fresh message entering into
> > Synapse. yet, this is the response to the original me
> >
> > So, what we need per IN-Message is another level of abstraction that
> > does not change with newing SynapseMessage. Let's Call this
> > MediationContext.
> >
> > So when a message enters into Synapse there is only one MediationContext
> > exist for all of this message mutations until the return comes back to
> > SynapseMessageReceiver, to select between 200/202 OK.
> >
> > So this MediatonContext can be used to keep state across mediators for a
> > given message.
> >
> > Please see Figure1.
> >
> > Please be kind enough to express your consensus on prior.
> >
> > Thank you
> >
> > Saminda
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Proposal to keep states
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi All,
These days I am working on a message bridge that connect two JMS domains. So from that experience, I also believe that we should not keep the state inside the synapse for messages. This will bind us to use a single synapse instance for related messages and we will not be able to handle them using several synapse instances.( may be connected through some message queue)
Thanks,
- Jaliya
----- Original Message -----
From: Paul Fremantle
To: synapse-dev@ws.apache.org
Sent: Thursday, February 02, 2006 7:59 AM
Subject: Re: Proposal to keep states
Saminda
I am very against us doing this.
The aim of Synapse is to be widely deployed and clustered. This design assumes that the messages come back to a single synapse server and also that the server has not failed in the meantime.
There are two solutions to this problem. The first solution is to use the WS-Addressing Reference parameters to include as much information as required in the message itself.
The second solution is to use a process (BPEL) server.
I strongly support us keeping Synapse stateless for very high performance, clustering and failover.
Paul
On 2/2/06, Saminda Abeyruwan < samindaa@gmail.com> wrote:
Hi Devs,
Problem : Synapse needs a way to keep track of status of the incoming message.
Use case: Assume a message comes (IN-Path) to Synapse and it is subjected to few rules such as route to the destination1, once the response returns to Synapse (if), again the message process through Synapse and hit another rule to say route the message destination2. Once the response return (hopfully) we need to send THIS processed response message again to to the initiator of the original message (the Client).
Now during the above process we "new" SynaspeMessages and MessageContext in Synapse, thus, this will restrain the ability of keeping the state of THIS message.
As there is no such mechanism involved, there is no way Synapse to know whether to trigger transport level details of Axis2 such as choosing between 200 OK and 202 OK.
Proposal
At present there is only ONE SynapseEnvironment available for every message that is coming into Synapse. (This is analogues to Axis2's ConfigurationContext)
According to the architecture <send/> will create a new SynapseMessage when the response comes to a outbound message. So it it obvious that <send/> is the last "Mediator" that should be in the mediator chain, before newing another SynapseMessage to inject the response back into Synapse. This is equivalent of treating this message as a fresh message entering into Synapse. yet, this is the response to the original me
So, what we need per IN-Message is another level of abstraction that does not change with newing SynapseMessage. Let's Call this MediationContext.
So when a message enters into Synapse there is only one MediationContext exist for all of this message mutations until the return comes back to SynapseMessageReceiver, to select between 200/202 OK.
So this MediatonContext can be used to keep state across mediators for a given message.
Please see Figure1.
Please be kind enough to express your consensus on prior.
Thank you
Saminda
---------------------------------------------------------------------
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
Re: Proposal to keep states
Posted by Paul Fremantle <pz...@gmail.com>.
Alek
So yes I agree that BPEL may not be the best/only approach. I guess my point
is that I think there is value in separating a runtime which is stateless
from one which is stateful.
If we encode all the "per message" state into each message (cookie or WS-A),
then Synapse can do everything required without losing scalability. For
example, the return message can be handled by a different JVM than the
request message without any requirement to share state across the two JVMs.
The stateful model where I keep state *related to a message* between
interactions is harder. It requires a complex infrastructure to allow the
session data to be copied across the cluster. Typically solutions use a
model like Tangosol or JGroups to do this, but to make the performance scale
linearly as you add machines to the cluster is almost impossible.
So I strongly approve of us doing the model where the state required is
added into the WS-A headers.
There is also work going on in Axis2 to address the clustered sessions, but
I think we should target a separate process manager or stateful
orchestration bus as a distinct second step.
Paul
On 2/2/06, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
> Paul Fremantle wrote:
>
> > I am very against us doing this.
> >
> > The aim of Synapse is to be widely deployed and clustered. This design
> > assumes that the messages come back to a single synapse server and
> > also that the server has not failed in the meantime.
>
> > There are two solutions to this problem. The first solution is to use
> > the WS-Addressing Reference parameters to include as much information
> > as required in the message itself.
>
> hi,
>
> state information (or pointer to it) can be also encoded in HTTP cookies
> (and/or in ordinary SOAP headers or even SOAP body payload - and the
> latter is actually used in BPEL to route messages ...).
>
> > The second solution is to use a process (BPEL) server.
>
> i think stock BPEL will not be good enough as it can not access SOAP
> headers and in particular WSA headers that are used in Synapse for
> routing so some kind of extension seems to be needed - maybe a special
> partner that exposes whole SOAP envelope? do you know any example of
> such "routing enabled" BPEL?
>
> i thought quite a bit about this problem and i am very interested to see
> if somebody also looked into it?
>
> > I strongly support us keeping Synapse stateless for very high
> > performance, clustering and failover.
>
> why not to allow some kind of a pluggable way for mediators to have
> state injected into them: before "stateful" mediator continues execution
> a mediator controller is called for "stateful" mediators to inject state
> into them: the simplest for users would be to use continuations (maybe
> not in Java but using a scripting engine and resume/suspend script state
> including their local stack) or just make it possible to access some
> kind of persistent store (database) from a "stateful" mediator ...
>
> on the other hand if it is not possible to do in Synapse (or out of
> scope) maybe there should be a (sub)project to do such stateful
> WS-router possible (with BPEL, scripting etc.)?
>
> best,
>
> alek
>
> >
> > Paul
> >
> > On 2/2/06, *Saminda Abeyruwan* < samindaa@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hi Devs,
> >
> > /Problem/ : Synapse needs a way to keep track of status of the
> > incoming message.
> >
> > /Use case/: Assume a message comes (IN-Path) to Synapse and it is
> > subjected to few rules such as route to the destination1, once the
> > response returns to Synapse (if), again the message process
> > through Synapse and hit another rule to say route the message
> > destination2. Once the response return (hopfully) we need to send
> > THIS processed response message again to to the initiator of the
> > original message (the Client).
> >
> > Now during the above process we "new" SynaspeMessages and
> > MessageContext in Synapse, thus, this will restrain the ability of
> > keeping the state of THIS message.
> >
> > As there is no such mechanism involved, there is no way Synapse to
> > know whether to trigger transport level details of Axis2 such as
> > choosing between 200 OK and 202 OK.
> >
> > /Proposal/
> >
> > At present there is only ONE SynapseEnvironment available for
> > every message that is coming into Synapse. (This is analogues to
> > Axis2's ConfigurationContext)
> >
> > According to the architecture <send/> will create a new
> > SynapseMessage when the response comes to a outbound message. So
> > it it obvious that <send/> is the last "Mediator" that should be
> > in the mediator chain, before newing another SynapseMessage to
> > inject the response back into Synapse. This is equivalent of
> > treating this message as a fresh message entering into Synapse.
> > yet, this is the response to the original me
> >
> > So, what we need per IN-Message is another level of abstraction
> > that does not change with newing SynapseMessage. Let's Call this
> > MediationContext.
> >
> > So when a message enters into Synapse there is only one
> > MediationContext exist for all of this message mutations until the
> > return comes back to SynapseMessageReceiver, to select between
> > 200/202 OK.
> >
> > So this MediatonContext can be used to keep state across mediators
> > for a given message.
> >
> >
> > Please see Figure1.
> >
> > Please be kind enough to express your consensus on prior.
> >
> > Thank you
> >
> > Saminda
> >
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com <ma...@wso2.com>
> >
> > "Oxygenating the Web Service Platform", www.wso2.com <
> http://www.wso2.com>
>
>
>
> --
> 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
Re: Proposal to keep states
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Paul Fremantle wrote:
> I am very against us doing this.
>
> The aim of Synapse is to be widely deployed and clustered. This design
> assumes that the messages come back to a single synapse server and
> also that the server has not failed in the meantime.
> There are two solutions to this problem. The first solution is to use
> the WS-Addressing Reference parameters to include as much information
> as required in the message itself.
hi,
state information (or pointer to it) can be also encoded in HTTP cookies
(and/or in ordinary SOAP headers or even SOAP body payload - and the
latter is actually used in BPEL to route messages ...).
> The second solution is to use a process (BPEL) server.
i think stock BPEL will not be good enough as it can not access SOAP
headers and in particular WSA headers that are used in Synapse for
routing so some kind of extension seems to be needed - maybe a special
partner that exposes whole SOAP envelope? do you know any example of
such "routing enabled" BPEL?
i thought quite a bit about this problem and i am very interested to see
if somebody also looked into it?
> I strongly support us keeping Synapse stateless for very high
> performance, clustering and failover.
why not to allow some kind of a pluggable way for mediators to have
state injected into them: before "stateful" mediator continues execution
a mediator controller is called for "stateful" mediators to inject state
into them: the simplest for users would be to use continuations (maybe
not in Java but using a scripting engine and resume/suspend script state
including their local stack) or just make it possible to access some
kind of persistent store (database) from a "stateful" mediator ...
on the other hand if it is not possible to do in Synapse (or out of
scope) maybe there should be a (sub)project to do such stateful
WS-router possible (with BPEL, scripting etc.)?
best,
alek
>
> Paul
>
> On 2/2/06, *Saminda Abeyruwan* < samindaa@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Devs,
>
> /Problem/ : Synapse needs a way to keep track of status of the
> incoming message.
>
> /Use case/: Assume a message comes (IN-Path) to Synapse and it is
> subjected to few rules such as route to the destination1, once the
> response returns to Synapse (if), again the message process
> through Synapse and hit another rule to say route the message
> destination2. Once the response return (hopfully) we need to send
> THIS processed response message again to to the initiator of the
> original message (the Client).
>
> Now during the above process we "new" SynaspeMessages and
> MessageContext in Synapse, thus, this will restrain the ability of
> keeping the state of THIS message.
>
> As there is no such mechanism involved, there is no way Synapse to
> know whether to trigger transport level details of Axis2 such as
> choosing between 200 OK and 202 OK.
>
> /Proposal/
>
> At present there is only ONE SynapseEnvironment available for
> every message that is coming into Synapse. (This is analogues to
> Axis2's ConfigurationContext)
>
> According to the architecture <send/> will create a new
> SynapseMessage when the response comes to a outbound message. So
> it it obvious that <send/> is the last "Mediator" that should be
> in the mediator chain, before newing another SynapseMessage to
> inject the response back into Synapse. This is equivalent of
> treating this message as a fresh message entering into Synapse.
> yet, this is the response to the original me
>
> So, what we need per IN-Message is another level of abstraction
> that does not change with newing SynapseMessage. Let's Call this
> MediationContext.
>
> So when a message enters into Synapse there is only one
> MediationContext exist for all of this message mutations until the
> return comes back to SynapseMessageReceiver, to select between
> 200/202 OK.
>
> So this MediatonContext can be used to keep state across mediators
> for a given message.
>
>
> Please see Figure1.
>
> Please be kind enough to express your consensus on prior.
>
> Thank you
>
> Saminda
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com <http://www.wso2.com>
--
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: Proposal to keep states
Posted by Paul Fremantle <pz...@gmail.com>.
Saminda
I am very against us doing this.
The aim of Synapse is to be widely deployed and clustered. This design
assumes that the messages come back to a single synapse server and also that
the server has not failed in the meantime.
There are two solutions to this problem. The first solution is to use the
WS-Addressing Reference parameters to include as much information as
required in the message itself.
The second solution is to use a process (BPEL) server.
I strongly support us keeping Synapse stateless for very high performance,
clustering and failover.
Paul
On 2/2/06, Saminda Abeyruwan <sa...@gmail.com> wrote:
>
> Hi Devs,
>
> *Problem* : Synapse needs a way to keep track of status of the incoming
> message.
>
> *Use case*: Assume a message comes (IN-Path) to Synapse and it is
> subjected to few rules such as route to the destination1, once the response
> returns to Synapse (if), again the message process through Synapse and hit
> another rule to say route the message destination2. Once the response return
> (hopfully) we need to send THIS processed response message again to to the
> initiator of the original message (the Client).
>
> Now during the above process we "new" SynaspeMessages and MessageContext
> in Synapse, thus, this will restrain the ability of keeping the state of
> THIS message.
>
> As there is no such mechanism involved, there is no way Synapse to know
> whether to trigger transport level details of Axis2 such as choosing between
> 200 OK and 202 OK.
>
> *Proposal*
>
> At present there is only ONE SynapseEnvironment available for every
> message that is coming into Synapse. (This is analogues to Axis2's
> ConfigurationContext)
>
> According to the architecture <send/> will create a new SynapseMessage
> when the response comes to a outbound message. So it it obvious that <send/>
> is the last "Mediator" that should be in the mediator chain, before newing
> another SynapseMessage to inject the response back into Synapse. This is
> equivalent of treating this message as a fresh message entering into
> Synapse. yet, this is the response to the original me
>
> So, what we need per IN-Message is another level of abstraction that does
> not change with newing SynapseMessage. Let's Call this MediationContext.
>
> So when a message enters into Synapse there is only one MediationContext
> exist for all of this message mutations until the return comes back to
> SynapseMessageReceiver, to select between 200/202 OK.
>
> So this MediatonContext can be used to keep state across mediators for a
> given message.
>
> Please see Figure1.
>
> Please be kind enough to express your consensus on prior.
>
> Thank you
>
> Saminda
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Proposal to keep states
Posted by Deepal Jayasinghe <de...@gmail.com>.
I also think it is better to have a place to keep status across all the mediators in the execution , and I think that will equivalent to OperationContext in Axis2 (am I correct ?) , and I can not see any disadvantage of having separate context for a mediation ..
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: Saminda Abeyruwan
To: synapse-dev@ws.apache.org
Sent: Thursday, February 02, 2006 12:32 PM
Subject: Proposal to keep states
Hi Devs,
Problem : Synapse needs a way to keep track of status of the incoming message.
Use case: Assume a message comes (IN-Path) to Synapse and it is subjected to few rules such as route to the destination1, once the response returns to Synapse (if), again the message process through Synapse and hit another rule to say route the message destination2. Once the response return (hopfully) we need to send THIS processed response message again to to the initiator of the original message (the Client).
Now during the above process we "new" SynaspeMessages and MessageContext in Synapse, thus, this will restrain the ability of keeping the state of THIS message.
As there is no such mechanism involved, there is no way Synapse to know whether to trigger transport level details of Axis2 such as choosing between 200 OK and 202 OK.
Proposal
At present there is only ONE SynapseEnvironment available for every message that is coming into Synapse. (This is analogues to Axis2's ConfigurationContext)
According to the architecture <send/> will create a new SynapseMessage when the response comes to a outbound message. So it it obvious that <send/> is the last "Mediator" that should be in the mediator chain, before newing another SynapseMessage to inject the response back into Synapse. This is equivalent of treating this message as a fresh message entering into Synapse. yet, this is the response to the original me
So, what we need per IN-Message is another level of abstraction that does not change with newing SynapseMessage. Let's Call this MediationContext.
So when a message enters into Synapse there is only one MediationContext exist for all of this message mutations until the return comes back to SynapseMessageReceiver, to select between 200/202 OK.
So this MediatonContext can be used to keep state across mediators for a given message.
Please see Figure1.
Please be kind enough to express your consensus on prior.
Thank you
Saminda
------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org