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
