When Registering a running Connector Manager to the GSA, it shuts down the TraversalScheduler and it is not restarted

[GoogleCodeExporter]

When you register a Connector Manager with the GSA it seems to initiate a
shutdown of the TraversalScheduler and kills all the running
WorkQueueThreads.  This is probably necessary to re-instantiate everything
after the applicationContext.properties file is updated.  Not a problem so far.

Problem is, the TraversalSchedule is never restarted.  So if you start
adding connectors to the newly registered Connector Manager - they will
never start feeding.  The TraversalScheduler and WorkQueueThreads need to
be restarted after the Connector Manager is registered.

There is a work around to stop and restart the Tomcat hosting the Connector
Manager.  This results in the normal startup and the TraversalSchedule is
running on a thread and any created Connectors start pushing documents.
martyg on December 03 2007 14:10 (New)
Stack trace on the Connector Manager side during this event as follows:

Context.setConnectorManagerConfig(String, int) line: 402
ProductionManager.setConnectorManagerConfig (String, int) line: 281
SetManagerConfigHandler.<init>(Manager, String) line: 60
SetManagerConfig.processDoPost(String, Manager, PrintWriter) line: 37
SetManagerConfig(ConnectorManagerServlet).doPost(HttpServletRequest,
HttpServletResponse) line: 96
SetManagerConfig(HttpServlet).service(HttpServletRequest,
HttpServletResponse) line: 709
SetManagerConfig(HttpServlet).service(ServletRequest, ServletResponse)
line: 802

The shutdown happens in Context.setConnectionManagerConfig().  If you look
at the CM server in a debugger you'll notice it starts with a bunch of
daemon threads and WorkQueueThread's.  These WorkQueueThread's run the
scheduling.  After the shutdown and restart, only the daemon threads are
restarted.  The WorkQueueThreads are not.
jeffling on December 18 2007 07:53 (New)
Hotlist
Connector Manager, GSA 07 Q4 - deprecated, use "GSA 5.0 Service Pack", Jeff
connector List

Problem is the Context.startScheduler() doesn't restart the threads if a
previous scheduler exists. This is a nasty bug.  The SetManagerServlet
takes a while since it has to try to gracefully shutdown all the current
work threads.  The GSA is very impatient and keeps calling the
SetManagerConfig Servlet over and over when it doesn't get an quick
response.  Therefore, if I just fix this to restart the traverserScheduler
each time it results in multiple scheduler threads when we only want one.

Might have to rework the SetManagerServlet.

Original issue reported on code.google.com by jeffreyl...@gmail.com on 21 May 2008 at 11:08

[GoogleCodeExporter]

Fixed in Connector Manager revision r878 

The previous incarnation attempted to handle feed host/port
changes by shutting down the webapp and trying to restart it.

As it is, only one thing cared about the feed host and port
(outside of the Context) - GsaFeedConnection.  So I added a 
setter method to GsaFeedConnection that takes the host and port
and call that from Context.setConnectorManagerConfig().  The
next document pushed will be pushed to the new feed host/port.

No shutting down of the web app or restarting Tomcat is neccessary.

Change Log:
----------
M  source/java/com/google/enterprise/connector/pusher/GsaFeedConnection.java
   - New setFeedHostAndPort() method regenerates the feed URL used.

M  source/java/com/google/enterprise/connector/manager/Context.java
   - setConnectorManagerConfig() calls GsaFeedConnection.setFeedHostAndPort()
     (and also refreshes the Context's cached gsaFeedHost variable), 
     rather than shutting down and restarting.

Original comment by Brett.Mi...@gmail.com on 3 Jul 2008 at 8:09

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mgron...@gmail.com on 3 Jul 2008 at 4:56

• Added labels: Milestone-Release_1.1.0