JDBC connection bug, possible fix?

[Adam Harding]

I had a situation where XNAT login attempts (and, as it turns out,
anything else requiring a database lookup) would fail, throw a broken
pipe SocketException and print the stack trace on the login page. This
happened with a database running on the local (to XNAT) system, and
postgresql appeared to be running fine the whole time, so I don't know
what the cause was. The only solution I found was to restart the XNAT
process. In attempting to reproduce the behavior, I found the
following:

start XNAT with the backing database running:
normal operation.

start XNAT with the backing database running, restart the database
without hitting it from XNAT while it's down:
XNAT reports "The backend has broken the connection. Possibly the
action you have attempted has caused it to close."
Subsequent attempts print the stack trace, persisting until opening a
new browser window/tab or entering the initial url afresh (looks like
it holds the variable for subsequent POSTs otherwise).

start XNAT with the backing database running, stop the database and
hit it while it's down:
XNAT prints the stack trace in its Welcome/Goodbye/<miscMessages> box
above the User/Password fields immediately.

It seems there is no recovery from the broken connection other than to
restart the XNAT process.

The standard(/modern?) way of doing this is to let the container
handle a pool of database connections and just interact with the
container. For example, our in-house Tomcat apps use this, and we can
manage the connections themselves with attributes in the standard
datasource definition. They generally mitigate or prevent dead
connections and survive this sort of situation transparently (as long
as the database and any interposed networking are operating, of
course).

Here is the stack trace in question:
An I/O error has occured while flushing the output - Exception:
java.net.SocketException: Broken pipe Stack Trace:
java.net.SocketException: Broken pipe at
java.net.SocketOutputStream.socketWrite0(Native Method) at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at
java.net.SocketOutputStream.write(SocketOutputStream.java:136) at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at org.postgresql.core.PGStream.flush(PGStream.java:411) at
org.postgresql.core.QueryExecutor.sendQueryV3(QueryExecutor.java:337)
at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:121)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43) at
org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:
517) at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:
50) at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
233) at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
221) at
org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:
205) at org.nrg.xft.db.PoolDBUtils.executeSelectQuery(PoolDBUtils.java:
490) at org.nrg.xft.search.TableSearch.Execute(TableSearch.java:205)
at org.nrg.xft.search.ItemSearch.getIdentifierResults(ItemSearch.java:
323) at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:431) at
org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:121) at
org.nrg.xdat.security.XDATUser.(XDATUser.java:94) at
org.nrg.xnat.security.LDAPAuthenticator.authenticate(LDAPAuthenticator.java:
470) at
org.nrg.xdat.security.Authenticator.Authenticate(Authenticator.java:
60) at
org.nrg.xdat.turbine.modules.actions.XDATLoginUser.doPerform(XDATLoginUser.java:
89) at
org.apache.turbine.modules.actions.VelocityAction.doPerform(VelocityAction.java:
46) at
org.apache.turbine.util.velocity.VelocityActionEvent.perform(VelocityActionEvent.java:
82) at
org.apache.turbine.modules.actions.VelocityAction.perform(VelocityAction.java:
72) at org.apache.turbine.modules.ActionLoader.exec(ActionLoader.java:
96) at
org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:
113) at org.apache.turbine.modules.Page.build(Page.java:53) at
org.apache.turbine.modules.PageLoader.exec(PageLoader.java:98) at
org.apache.turbine.Turbine.doGet(Turbine.java:751) at
org.apache.turbine.Turbine.doPost(Turbine.java:846) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
290) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
206) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
233) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
191) at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:
465) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109) at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
298) at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
852) at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:588) at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
489) at java.lang.Thread.run(Thread.java:619) End of Stack Trace

I can see a couple things to improve:
1) Make the "nice" report catch repeated attempts (which users will no
doubt elicit), and provide a note about informing a designated point
of contact. For that will require immediate attention like this, it
would be best to have a user-configurable list of contacts, even if
just the contents of a plaintext file, say.

2) Change the database definition in XNAT's code to use a Tomcat
datasource, perhaps providing some reasonable suggestions for the
datasource definition that should work for most production XNAT
instances, in case the site implementer needs it.

We view this as a fairly serious point of failure in light of the
robustness that's available, and have some in-house experience with
(2) & so can probably provide suggestions or perhaps assistance.

We may also look at upgrading the JDBC driver as needed; cf:
http://groups.google.com/group/xnat_discussion/browse_thread/thread/2b0ed41fe83a244f/5649542610e5a3bd?lnk=gst&q=jdbc3#5649542610e5a3bd

Thanks,
Adam

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To post to this group, send email to xnat_di...@googlegroups.com.
To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xnat_discussion?hl=en.

[Timothy Olsen]

XNAT is supposed to be robust to flushing out stale connections and creating new ones. This sounds like a bug that needs to be fixed.

XNAT uses the commons dbcp package to handle db connection pooling. This has worked well for us in the past, with the exception of this issue. Generally we don't run into this issue, as our PostgreSQL is rarely restarted. However, I agree that it is a significant issue. This would be particularly important on a high availability Postgres cluster, which may re-route connections to another db host making them appear stale (at least, so I hear).

We've considered moving to the Tomcat datasource in the past. However, there are several places where XNAT currently connects to the database from outside of the web application. This led XNAT to manage its own connection pooling.

XNAT can be instantiated outside of Tomcat and used to store xml directly to the database (with the same permissions as normal).
Historically, this was a common use case. It's pretty rare now that we have more robust web services to support this. It still does this external instantiation when you store your initial security.xml. This is something that we are planning on eliminating in future versions.

Also, the update.sh script accesses your database to generate an update.sql which will create any missing tables/columns (usually triggered by the addition of a new schema). We plan on moving this into the webapp at some point, but, for now, it is what it is, and requires its own connection to the database.

At some point, we hope to move XNAT to a WAR only solution. At that point nothing would connect to the database, other than the Tomcat app. When we get there, moving to Tomcat's datasource may make good sense. But, until then I think we'll need to continue to manage our own connections.

FYI, you can configure the connection pool size in the WEB-INF/conf/InstanceSettings.xml.

I'll review the connection pooling code and resolve the bug. I'll let you know when its available for testing (probably early next week).

Thanks for your advice.

Tim

[Timothy Olsen]

Adam,

I believe I've resolved the DB connection bug. The code should now properly drop the old connections, and retry with a new connection.

It has satisfied my testing. Would you mind testing it in your site?

Download this file:

http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/xdat/jars/xdat-1.jar?view=co

And place it in XNAT_HOME/plugin-resources/repository/xdat/jars/. Running the update.sh would build the WAR (or deploy if you choose). Or you could cut out the middle man and copy it directly to your webapps/XNAT/WEB-INF/lib/ directory.

Tim

-----Original Message-----
From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com] On Behalf Of Adam Harding
Sent: Friday, April 16, 2010 1:09 PM
To: xnat_discussion
Subject: JDBC connection bug, possible fix?

[Adam Harding]

I tried dropping the jar directly into webapps/xnat/WEB-INF/lib/ but
this produced an error with this banner (after a restart):

"An error has occured.
Please contact your IT staff or the application logs for more
information."

There was a ResourceNotFoundException exception error in turbine.log
and several errors in velocity.log.

Restoring the original jar file restores normal operation.

Perhaps the .jar file at the indicated URL has since been updated to
depend on other updates? I can post logs as required.

Thanks,
Adam

On Apr 19, 2:22 pm, Timothy Olsen <t...@npg.wustl.edu> wrote:
> Adam,
>
> I believe I've resolved the DB connection bug.  The code should now properly drop the old connections, and retry with a new connection.
>
> It has satisfied my testing.  Would you mind testing it in your site?
>
> Download this file:
>

> http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/...

>
> And place it in XNAT_HOME/plugin-resources/repository/xdat/jars/.  Running the update.sh would build the WAR (or deploy if you choose).  Or you could cut out the middle man and copy it directly to your webapps/XNAT/WEB-INF/lib/ directory.
>
> Tim
>
> -----Original Message-----
> From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com] On Behalf Of Adam Harding
> Sent: Friday, April 16, 2010 1:09 PM
> To: xnat_discussion
> Subject: JDBC connection bug, possible fix?
>

> I had a situation where XNATloginattempts (and, as it turns out,

> anything else requiring a database lookup) would fail, throw a broken

> pipe SocketException and print the stack trace on theloginpage. This

> We may also look at upgrading the JDBC driver as needed; cf:http://groups.google.com/group/xnat_discussion/browse_thread/thread/2...

>
> Thanks,
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
> To post to this group, send email to xnat_di...@googlegroups.com.
> To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/xnat_discussion?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
> To post to this group, send email to xnat_di...@googlegroups.com.
> To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/xnat_discussion?hl=en.

[Olsen, Timothy]

The jar change should not require any other updates. It is not dependent on anything that changed. The only risk would have been that something in the released version depended on something in the jar which changed. But, I've reviewed the modifications and this should not be the case. You should be fine using the most recent jar on in the current release.

I setup the released version on a test server and plugged in the newest jar. I did not receive the issues you are reporting. Did you receive the error upon trying to access the login page? Or was it after clicking something in the site.

Is there a chance that the xdat-1.jar file was corrupted? I noticed that IE tried to rename the file to xdat-1.zip. Can you try re-downloading the file and overwriting the jar in the WEB-INF lib?

Beyond this, it may be helpful to see the rest of the ResourceNotFoundException. Also, were there any errors in catalina.out or in the xdat.log?

Thanks for your patience here.

[Olsen, Timothy]

One additional question, did you deploying using a WAR or the deploy=true option? I'd like to make sure I'm testing the same thing.

[Adam Harding]

Thanks, for checking. I deployed using the deploy=true option
(standalone in our environment).

I made a backup of the original jar, shut down XNAT, overwrote the old
version in webapps/xnat/WEB-INF/lib/ with the new version, relaunched,
and encountered the error when trying to access the login page.

On inspection, it does look like the jar was corrupt. I re-downloaded
it on a few different systems and now seem to have a good copy, and
used the same procedure with it. (Perhaps a checksum/hash would be
useful; not sure if viewvc does this..)

I launched XNAT with the updated jar and verified normal operation.
For testing, I then stopped the database.
1) The first login attempt always displays the "backend has broken the
connection" error notice.
2) All subsequent page reloads, with or without additional login
attempts, still print the stack trace rather than the error notice.
3) A new browser session displays the normal login page with no
notice, then displays the stack trace instead of the warning upon
attempted login.
4) After relaunching the database, the behavior remains as in (2) and
(3).

I then restarted XNAT:
6) Simply reloading the login page with either the stack trace or
"backend...connection" error printed, resending cached credentials,
results in successful login.

Next, I tried establishing a connection, then restarting the database
without intervening login attempts.
7) Attempting to log in with a new browser session results in the
"backend...connection" error, and subsequent attempts print the stack
trace.
8) This persists until XNAT is restarted, and then the behavior is as
in (6).

What type of connection failure did you have it survive? I'm still
having to relaunch the application to restore connectivity.

Adam

> ...
>
> read more »

[Olsen, Timothy]

Adam,

I'm looking into this. I'm seeing different results on my server. The only error message I ever see is (in a pretty pink box):

'Cannot create PoolableConnectionFactory (Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.)'

Or the standard 'An error has occurred page'.

As soon as I restart PostgreSQL the issue goes away, and the site behaves normally (without a restart).

That said, there is one complication. XNAT currently needs a PostgreSQL at server init. If it doesn't have a connection then, it will have issues. I can test that scenario, and try to make it handle the problem more gracefully. But that would be a very rare scenario for us.

I can work on rebuilding a jar with some precise logging to guarantee we are hitting the same version of the code. I'll try to get that to you tomorrow afternoon.

[Adam Harding]

The behavior you're getting is what I was expecting, but I still don't
see a change from before. It does seem noteworthy that I'm seeing the
same behavior as before dropping the jar into place, as if the jar I'm
using either isn't being [re-]read (some sort of caching?) or isn't
the one that incorporates your changes. I'm using revision 1.238 as
available at this page:
http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/xdat/jars/xdat-1.jar

I have:
$ openssl dgst -sha1 xdat-1.jar
[or: openssl sha1 xdat-1.jar ]
SHA1(xdat-1.jar)= 842f279e1f9e045a67cab25e1b53128d2861d16b

I also notice there are copies at xnat/pipeline/lib/xdat-1.jar and
xnat/lib/xdat-1.jar in addition to the one used during deployment/
building at xnat/plugin-resources/repository/xdat/jars/. Pipeline's
jar is different, but I presume this has no bearing on the current
problem.

I'm using RHEL5's original version (8.1) of PostgreSQL, running on the
same system ( with xdat.project.db.connection.string=jdbc:postgresql://
localhost/dbname ) and haven't tinkered with the JDBC driver.

>XNAT currently needs a PostgreSQL at server init. If it doesn't have a connection then, it will have issues. ...that would be a very rare scenario for us.

It's probably pretty rare in general, but that would be a good
robustness improvement as long as the fix doesn't involve too major a
change. Probably good to make a note of the requirement in the
instructions too even though it's a common-sense thing. I agree that
the fix you've described, for the typical case, is the more important
one.

Thanks for looking into this.
Adam

[Olsen, Timothy]

SHA1 matches. I've tested both the 1.238 and 1.239. I'm still different results. Perhaps, your PostgreSQL is throwing a slightly different exception that's not caught by our filter.

Can you include the most recent stacktrace of the exception? It should be slightly different than the previous one.

[Adam Harding]

First: this was printed in the browser. Following is from xdat.log,
showing the attempt to log in followed by a page refresh:

An I/O error has occured while flushing the output - Exception:
java.net.SocketException: Broken pipe Stack Trace:
java.net.SocketException: Broken pipe at
java.net.SocketOutputStream.socketWrite0(Native Method) at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at
java.net.SocketOutputStream.write(SocketOutputStream.java:136) at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at org.postgresql.core.PGStream.flush(PGStream.java:411) at
org.postgresql.core.QueryExecutor.sendQueryV3(QueryExecutor.java:337)
at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:121)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43) at
org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:
517) at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:
50) at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
233) at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
221) at
org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:

205) at org.nrg.xft.db.PoolDBUtils.executeQuery(PoolDBUtils.java:864)
at org.nrg.xft.db.PoolDBUtils.executeSelectQuery(PoolDBUtils.java:411)

at org.nrg.xft.search.TableSearch.Execute(TableSearch.java:205) at
org.nrg.xft.search.ItemSearch.getIdentifierResults(ItemSearch.java:
323) at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:431) at
org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:121) at

From xdat.log:

2010-05-10 15:41:05,113 [http-8080-2] ERROR
org.nrg.xdat.turbine.modules.actions.XDATLoginUser -
org.postgresql.util.PSQLException: The backend has broken the

connection. Possibly the action you have attempted has caused it to
close.

at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:168)
at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:
127)

at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:
517)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:
50)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
233)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
221)
at
org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:
205)

at org.nrg.xft.db.PoolDBUtils.executeQuery(PoolDBUtils.java:864)
at org.nrg.xft.db.PoolDBUtils.executeSelectQuery(PoolDBUtils.java:
411)

at org.nrg.xft.search.TableSearch.Execute(TableSearch.java:205)
at org.nrg.xft.search.ItemSearch.getIdentifierResults(ItemSearch.java:
323)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:431)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:121)

at org.nrg.xdat.security.XDATUser.<init>(XDATUser.java:94)

2010-05-10 15:41:12,408 [http-8080-3] ERROR
org.nrg.xdat.turbine.modules.actions.XDATLoginUser -
org.postgresql.util.PSQLException: An I/O error has occured while

at org.nrg.xft.db.PoolDBUtils.executeQuery(PoolDBUtils.java:864)
at org.nrg.xft.db.PoolDBUtils.executeSelectQuery(PoolDBUtils.java:
411)

at org.nrg.xft.search.TableSearch.Execute(TableSearch.java:205)
at org.nrg.xft.search.ItemSearch.getIdentifierResults(ItemSearch.java:
323)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:431)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:121)

at org.nrg.xdat.security.XDATUser.<init>(XDATUser.java:94)

at org.postgresql.core.PGStream.flush(PGStream.java:415)

at org.postgresql.core.QueryExecutor.sendQueryV3(QueryExecutor.java:
337)
at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:
121)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:
517)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:
50)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
233)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:
221)
at
org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:
205)

at org.nrg.xft.db.PoolDBUtils.executeQuery(PoolDBUtils.java:864)
at org.nrg.xft.db.PoolDBUtils.executeSelectQuery(PoolDBUtils.java:
411)

at org.nrg.xft.search.TableSearch.Execute(TableSearch.java:205)
at org.nrg.xft.search.ItemSearch.getIdentifierResults(ItemSearch.java:
323)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:431)
at org.nrg.xft.search.ItemSearch.exec(ItemSearch.java:121)

at org.nrg.xdat.security.XDATUser.<init>(XDATUser.java:94)

Adam

On May 10, 1:18 pm, "Olsen, Timothy" <t...@npg.wustl.edu> wrote:
> SHA1 matches.  I've tested both the 1.238 and 1.239.  I'm still different results. Perhaps, your PostgreSQL is throwing a slightly different exception that's not caught by our filter.
>
> Can you include the most recent stacktrace of the exception?  It should be slightly different than the previous one.
>
> Tim
>
> -----Original Message-----
> From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com] On Behalf Of Adam Harding
> Sent: Friday, May 07, 2010 3:22 PM
> To: xnat_discussion
> Subject: Re: JDBC connection bug, possible fix?
>
> The behavior you're getting is what I was expecting, but I still don't
> see a change from before. It does seem noteworthy that I'm seeing the
> same behavior as before dropping the jar into place, as if the jar I'm
> using either isn't being [re-]read (some sort of caching?) or isn't
> the one that incorporates your changes. I'm using revision 1.238 as

> available at this page:http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/...

[Olsen, Timothy]

Lets give this one more go. I've checked in an updated jar (1.240). This includes an improvement to my previous bug fix.

Please test this jar, and let me know the results.

http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/xdat/jars/xdat-1.jar?view=co

[Adam Harding]

Tim,

It looks like r1.240 behaves as desired: error message (without stack
trace) printed when the database is inaccessible, normal function when
it becomes available again, no restart of XNAT required. I'd say this
is fixed.

--------------------
One more related item: is it possible to modify the error message?

"Connection refused. Check that the hostname and port are correct and
that the postmaster is accepting TCP/IP connections."

This exactly describes the situation and possible resolution of
course, but it's displayed to end users as well as the sysadmins &
developers to whom it's pertinent. I'd like to change it so as not to
hide info from the latter while making it clear that it's not a
problem on the part of the former; something like this maybe:

"Database connection refused. Adminitrators: Check that the hostname

and port are correct and that the postmaster is accepting TCP/IP
connections."

I could rebuild the jar with a custom string if necessary, but a user-
friendlier default could benefit everyone's users.

Thanks for your persistence on this! It looks like the behavior is now
quite robust.

Adam

On May 11, 12:00 pm, "Olsen, Timothy" <t...@npg.wustl.edu> wrote:
> Lets give this one more go.  I've checked in an updated jar (1.240).  This includes an improvement to my previous bug fix.
>
> Please test this jar, and let me know the results.
>

> http://nrg.wustl.edu/viewvc/xdat_release/plugin-resources/repository/...