shutdown script, ws-policy, clustering for "dynamic" registries

[J Bouck <bo...@gmail.com>]

I'm on a platform where a daemon is not currently supported (HP-UX
11.23, JDK 1.6.0, synapse 1.1.1).  Could anyone suggest a shutdown
script for synapse that's a bit more graceful than a kill on the PID?
I would hate to kill Synapse in the midst of a proxy transaction.  Is
there a way to stop incoming transactions (close the port or return an
appropriate http status code) for a minute or two and then shutdown
synapse when proxy transactions have completed?

Can WS-Policy be applied to other inbound-to-synapse services not
defined as proxy services?  It looks like a ws-policy can be applied
to endpoints, but not to inbound non-proxy services.  True?

I understand that you can't make a registry-based synapse
configuration dynamic, but couldn't a clustered environment appear to
be dynamic if you use a full registry-based configuration (like sample
11).  With 2 instances of Synapse sharing the same configuration file,
you update the shared configuration file with the new configuration,
restart instance#1 with the new configuration while instance#2 has the
old configuration and then restart instance#2 with the new
configuration.  With an apache proxy for failover in front of the
cluster it would appear to have no downtime and the configuration
would change, wouldn't it?

~john

Re: shutdown script, ws-policy, clustering for "dynamic" registries

[Ruwan Linton <ru...@gmail.com>]

Hi john,

See my comments inline,

On Feb 4, 2008 11:26 PM, J Bouck <bo...@gmail.com> wrote:

> I'm on a platform where a daemon is not currently supported (HP-UX
> 11.23, JDK 1.6.0, synapse 1.1.1).  Could anyone suggest a shutdown
> script for synapse that's a bit more graceful than a kill on the PID?
> I would hate to kill Synapse in the midst of a proxy transaction.  Is
> there a way to stop incoming transactions (close the port or return an
> appropriate http status code) for a minute or two and then shutdown
> synapse when proxy transactions have completed?


AFAIK, you could do this with JMX by shutting down the synapse server
gracefully or by going in to the maintenance mode of the http transport
before shutting down. (this is implemented only over the http transport)
Asankha would be in a better position to answer this question in detail,
because he is the one who implemented this....


>
> Can WS-Policy be applied to other inbound-to-synapse services not
> defined as proxy services?  It looks like a ws-policy can be applied
> to endpoints, but not to inbound non-proxy services.  True?


Can you please explain what do you mean by *"other inbound-to-synapse
services not
defined as proxy services"*? If they are the services which are deployed on
the axis2 instance on which synapse is running, then the answer is true,
because they do not go through synapse, but you could add the security or
any other policy by configuring the services.xml to instruct the axis2
instance about the service policy directly, without going through
synapse???


> I understand that you can't make a registry-based synapse
> configuration dynamic, but couldn't a clustered environment appear to
> be dynamic if you use a full registry-based configuration (like sample
> 11).  With 2 instances of Synapse sharing the same configuration file,
> you update the shared configuration file with the new configuration,
> restart instance#1 with the new configuration while instance#2 has the
> old configuration and then restart instance#2 with the new
> configuration.  With an apache proxy for failover in front of the
> cluster it would appear to have no downtime and the configuration
> would change, wouldn't it?


Yes, you are correct and this is not really dynamic because you have to
restart the servers to get the configuration update to be effective on the
server, where as in true dynamic case you do not have to restart the server
to get the config updates to be effective on the servers.

This simulates the dynamic nature on a clustered environment, yes it is
true...

Thanks,
Ruwan


>
>
> ~john
>



-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Re: shutdown script, ws-policy, clustering for "dynamic" registries

["Asankha C. Perera" <as...@wso2.com>]

John
> I'm on a platform where a daemon is not currently supported (HP-UX
> 11.23, JDK 1.6.0, synapse 1.1.1).  Could anyone suggest a shutdown
> script for synapse that's a bit more graceful than a kill on the PID?
>   
Sure, just go to http://wrapper.tanukisoftware.org/ and get the binary 
for HP-UX and drop it into the bin/native directory and the Java service 
wrapper should do the rest for you.. we just haven't included the HP-UX 
binary as we do not have a test system for it with us.. but you could 
let us know if this works fine, and we could include it into the next 
release :)
> I would hate to kill Synapse in the midst of a proxy transaction.  Is
> there a way to stop incoming transactions (close the port or return an
> appropriate http status code) for a minute or two and then shutdown
> synapse when proxy transactions have completed?
>   
Sure, the http and https transports now support a "maintenance mode" 
where you could ask them to stop accepting *new* connections while 
continue processing already accepted messages without interruption. This 
could only be done via JMX right now. This effectively makes the Synapse 
instance appear offline to a proxy in front, which can then direct load 
to another instance. After all in-flight requests are served, you could 
shutdown and restart the server without interruption to the traffic 
which will be handled from the other instance.
> Can WS-Policy be applied to other inbound-to-synapse services not
> defined as proxy services?
You mean for "message mediation" ?.. the answer is no
>   It looks like a ws-policy can be applied
> to endpoints, but not to inbound non-proxy services.  True?
>   
Yes
> I understand that you can't make a registry-based synapse
> configuration dynamic, but couldn't a clustered environment appear to
> be dynamic if you use a full registry-based configuration (like sample
> 11).  With 2 instances of Synapse sharing the same configuration file,
> you update the shared configuration file with the new configuration,
> restart instance#1 with the new configuration while instance#2 has the
> old configuration and then restart instance#2 with the new
> configuration.  With an apache proxy for failover in front of the
> cluster it would appear to have no downtime and the configuration
> would change, wouldn't it?
>   
Absolutely, as explained above this is supported and was the original 
idea for the new 'maintenance mode' of the transports

asankha