Hi Eric
If all nodes are started via the wrapper, the index.jsp shows three nodes in Status
"Started" and everything looks fine. No connection refused exceptions on my
side. Besides an java.net.MalformedURLException showing in the JBoss server.log. It seems
as if addServer is called with a malformed String (maybe some default context param not
intended to be passed to the addServer method?). But that's not that important.
Hmm.. I am not sure what caused this, a stacktrace maybe helpful to try
to figure it out..
RESTART:
The same applies to this. The only thing is that during the restart the status
does not update. You can't see what's going on there. But it works.
Hmm.. this is because I did this quick JSP for illustration purposes,
and to be honest I am not a good JSP/UI engineer :-) .. I will check if
someone from my team can help me improve this to reflect the status and
refresh periodically etc..
One question: Is this restart graceful? I didn't try whether working processes
will get time to finish their work.
No, this is not graceful as this is invoking a JMX method on the Java
Service Wrapper - although our shutdown hook gets invoked, any messages
in-flight may get killed. However, there is a solution to this (see
comments on maintenance mode)
STOP:
What was your intention here? I thought it would stop the esb instance, but not the
controlling wrapper. You should be able to start it up again if you like. Stopping the
wrapper doesn't seem logical to me. If you do this, you will loose control. Or am I
wrong. I tried it and the wrapper stops. Subsequent calls of the index.jsp result in a
java.net.ConnectException: Connection refused exception. Of course this should not be the
case, even if an esb instance or its corresponding wrapper is down. On the other side the
status still reports "Started". So the status does not seem to work at all for
me. Now I have not possibility to bring this instance up again. Restart does not work,
because I lost the connection.
Yep, again I invoked on the stop() exposed via JMX by the service
wrapper.. The solution to handle this correctly as you suggest is to
shutdown - but not exit the VM, and will require some changes to the
core ESB code. Shall we file a new JIRA for this, so that we can get
this functionality into the next release? So far, I have not made any
changes to the core distribution to support this illustrative webapp..
However, I agree that your comments are valid and good
START_MAINTENANCE
What is this for? I guess it will stop the esb from accepting new requests
while requests which are processed or queued will finish their work. Is this
understanding correct?
Yes
So this feature might be useful for example if you notice problems on one
instance in a cluster. You could switch this instance to maintenance. A
loadbalancer in front would receive a connection refused and consider the esb
instance to be down while using other instances.
This sounds quite useful to me.
Yep, exactly. Also, this will let you first put a node into maintenance
and then shutdown or restart - so that in-flight messages will not be
affected. This also allows you to update configurations or do other
maintenance on a group of nodes without bringing down the whole system
asankha
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
