Troubleshooting Plugin Issues

Basic information

In Targetprocess most plugins work as standalone services. The technology is based on Message Queuing (MSMQ) component and NServiceBus to communicate with messages between a plugin and the core Targetprocess application.

The main advantage of this solution is that new plugins work as services which do not have to be installed on the same server with TargetProcess. This improves performance, reliability and makes it easier to develop new features. Unfortunately the new architecture brings in new technical issues, so let’s see how to troubleshoot them.

Your first step

If you see that some of the plugins are missing at Settings -> Plugins, it usually means that the corresponding services are stopped. The first thing to do is to go to the standard Windows Services on the server where Targetprocess is hosted and try to start them.

With some luck, the service starts and you can see the plugin in Targetprocess UI. Happy End!

If plugin service is unable to start

Check the logs

Plugins have separate log files that can provide valuable information. You can find them at

c:\inetpub\wwwroot\TargetProcess\Plugins\Plugin_name\Logs\Plugin.txt

Even if you cannot identify the problem right away, it would be most useful for the Targetprocess support team.

Hint: Plugin.txt can be quite large and difficult to read. The latest records are added to the end of the file. You can try the following trick: remove Plugin.txt from the Logs folder and then try to start the service. After that the log will contain only relevant information.

Most common plugin issues:

Too many messages in Private Queues

This happens if Message Queuing is not able to process messages and they just stuck.  Open Computer Manager and expand Services and Applications -> Message Queuing. Ideally we need 0 messages in all queues except tp.pluginsubcriptions - it should have several hundred messages.  If you have thousands of messages in private queues, it is usually a bad sign.

If you are not using a plugin which has a number of messages, you can delete them by expanding the queue -> Queue messages -> All tasks -> Purge.

However, purging the queue could result in some data loss. So be careful with that for the plugins you are using. Here are our recommendations:

Do not purge if:

1. It is tp.pluginsubscriptions. Just don't.
2. The number of messages is decreasing. Better let the system process the messages
3. You are using the plugin and it affects data in Targetprocess. This includes: tp.bugzilla, tp.git, tp.popemailintegration, tp.tfs, tp.webhooks

Purge if:

1. You are not using the plugin at all.  The best approach to deal with unused plugins is to uninstall them.
2. You can purge tp.search, but to get actual results you may need to rebuild indexes.
3. Nothing else helps

After purging the queue it is required to restart correspondent plugin service and in some cases - recycle Targetprocess application pool in IIS Manager.

Plugin configuration file points to the wrong database

This may happen if you move your database to another location. Changing TargetProcess web.config is not enough. Now each plugin has its own configuration file and these files need to be updated as well.

Database connection is configured at

c:\inetpub\wwwroot\TargetProcess\Plugins\Plugin_name\PluginSettings.config 
(e.g. ...\TargetProcess\Plugins\SubversionIntegration\PluginSettings.config)

Make sure that pluginDatabaseConnectionString uses the correct database and credentials. Usually the connection string should be the same as in ...TargetProcess\wwwrootweb.config.

Permissions for private queues

Open Computer Manager (Server Manager at Windows Server 2008), find Message Queuing under Features and expand Private Queues.

There are lots of queues here as you can see, but in terms of permissions there are two groups:

• Plugins and UI queues such as tp.bugzilla, tp.bugzillaui, tp.git, tp.gitui, tp.search, tp.searchui and similar queues with the plugin name. They need Full Control for SYSTEM and Administrators. To check that, right-click the name of the queue, pick Properties and switch to the Security tab.
  
• Internal or service queues: tp.error, tp.inputcommand, tp.inputcommandui, tp.pluginssubscriptions and all the tp.proxy.xxx queues. Apart from the permissions that the previous group has, these also need Full Control for the user specified as your Application Pool Identity.
  
  
  By default it is Network Service and we recommend keeping it this way. In some cases when you need the application to be run as a different user, that user needs Full Control for the following queues:
  

These are the most common issues, but not all the possible ones. If that does not help, contact Targetprocess support (it would be great if you attach the above-mentioned logs right away).