Better handling of null QueryTraversalManager

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a connector instance where Session.getQueryTraversalManager
throws an exception.

What is the expected output? What do you see instead?

In ConnectorInterfaces.getTraverser, the QueryTraversalManager variable qtm
remains null when the exception is thrown, but nothing else is done. The
QueryTraverser is instantiated with a null QueryTraversalManager and will
later throw a NullPointerException in runBatch, because null is not
handled. The runBatch method continues to be called periodically by the
scheduler, but it's never going to work.

Please use labels and text to provide additional information.

There a note in getTraverser about needing to do some kind of retry. It
seems like the scheduler needs to be told that it doesn't have a traverser
so that it can start at that point, rather than calling runBatch. Part of
the problem is that ConnectorInterfaces masks the error by constructing an
invalid QueryTraverser and then holding on to it. If it had a null
traverser field, then the retries from the scheduler would retry
getQueryTraversalManager and all would be well, beyond the initial
failures. Of course, some additional work might be needed for getTraverser
to fail gracefully when it fails to get a QueryTraversalManager. Even
something silly like returning the bogus QueryTraverser but not caching it
might work.

The workaround at the moment is to reload the connector-manager web
application in Tomcat (or restart Tomcat).

Original issue reported on code.google.com by jl1615@gmail.com on 12 Mar 2007 at 10:33

[GoogleCodeExporter]

Google Bug #658516

Original comment by vjo...@gmail.com on 15 Mar 2007 at 4:48

• Changed title: Better handling of null QueryTraversalManager

[GoogleCodeExporter]

To fix in ConnectorInterfaces.getTraverser(), you can move the creation of the 
new
QueryTraverser into the try{} block.  Then, if Session.getTraversalManager() 
fails
(or even if creation of QueryTraverser fails) then an invalid QueryTraverser is 
not
created and cached.  Since the cached QueryTraverser remains null, the next 
call to
getTraverser() will be the retry strategy that Max refers to in his comment.

The only caller of getTraverser() already handled a null return (poorly).  
However,
WorkQueueItems already tested for a null Traverser and subsequently don't do 
any work.

Original comment by Brett.Mi...@gmail.com on 2 May 2008 at 2:29

[GoogleCodeExporter]

Fixed in revision r805 which also addresses issue 60 and issue 63.

Original comment by Brett.Mi...@gmail.com on 25 May 2008 at 2:12

[GoogleCodeExporter]

Original comment by Brett.Mi...@gmail.com on 25 May 2008 at 2:17

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mgron...@gmail.com on 19 Jun 2008 at 6:35

• Added labels: Milestone-Release_1.1.0