[Jmri-developers] XmlIO Monitoring in JMRI

[Randall W. <ran...@al...>]

Steve, et al:

In looking into the recent issues some users have reported using the
monitoring capability of the XmlIO server, I have concluded that we need to
remove that capability. I would recommend instead:

1) encourage client developers to have XmlIO clients poll for information
instead of monitoring for it (more on this later),
2) develop a Web Socket mechanism in the web server to replace the XmlIO
monitoring functionality (modern browsers can use this on all platforms
except Android),
3) ensure that the Simple Server and XmlIO server are capable of reporting
on the same objects (for those types of objects that can change state).

Prior to introducing the Jetty server, XmlIO clients could reliably expect
that the XmlIO server would leave open an HTTP connection and report the
state of a monitored object if that object changed state (such as throwing
a turnout), or if a time limit was reached (5 minutes). The Jetty server
(along with, it appears most other commercial servers) does not scale well
to support that behavior (but does scale well to support other uses of the
web server--I had replaced our home-grown web server because a large number
of requests could severely impact JMRI performance). The reason the Jetty
server does not scale well to support that behavior has to do with the
Jetty server's internal mechanisms to ensure that it can handle a large
number of requests a second--it aggressively kills servlet threads that do
not respond within a fairly short period of time to ensure those resources
remain available.

Our XmlIO monitoring design is a fairly expensive design: it creates an
additional thread, attaches listeners to the monitored object from that
thread, and then waits for that thread to either respond or timeout, and
then tears everything down again; in every XmlIO client I've encountered,
an immediate client action upon receiving a response from the XmlIO server
is to repeat the original request (possibly with a different state based on
the response), which ensures the process is a continuous loop. Testing this
with logging in debug mode is, in fact, so process intensive, that the JMRI
system console cannot keep up with attempts to write to it, causing the
logger to throw exceptions.

So I suggest we remove the XmlIO monitoring capability.

Jetty includes a Web Socket server jar file and adding an XmlIO protocol
web socket service to the web server appears to be fairly easy.

So how should we handle users of the XmlIO monitoring capability? We should
(1) inform them of this change, and (2) ensure that the XmlIO server, even
though it is responding immediately, continues to honor all monitoring
requests.

Randall Wood
Alexandria Software
202.683.8604
ran...@al...
http://www.alexandriasoftware.com