Jiwa

Plugin encountered an exception when compiling during logon

Hi,

I'm getting these errors on my Production API server, it seems to happen within a few hours to a day of when these plugins are modified. It's not specific to any one plugin. I've seen at least three give this error.

Plugin 'plugin name' encountered an exception when compiling or loading during logon. Exception Message: 'System.IO.IOException: The process cannot access the file 'pluginname.dll' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
at Microsoft.VisualBasic.FileIO.FileSystem.CopyOrMoveFile(CopyOrMove operation, String sourceFileName, String destinationFileName, Boolean overwrite, UIOptionInternal showUI, UICancelOption onUserCancel)
at Microsoft.VisualBasic.MyServices.FileSystemProxy.CopyFile(String sourceFileName, String destinationFileName, Boolean overwrite)
at JiwaFinancials.Jiwa.JiwaApplication.Plugin.Plugin.LoadAssembly()
at JiwaFinancials.Jiwa.JiwaApplication.Plugin.Plugin.Load()
at JiwaFinancials.Jiwa.JiwaApplication.Plugin.PluginCollection.()
at JiwaFinancials.Jiwa.JiwaApplication.StartupLog.Add(String Description, Action CallbackMethod)
at JiwaFinancials.Jiwa.JiwaApplication.Plugin.PluginCollection.Compile()

It's causing errors like "Custom field with Setting Name 'OpportunityID' not found" when making requests to our API, i'm guessing, because the plugin containing that custom field isn't compiling.
But it could be session based, because I made a request from a different device (with different user & token, and a SalesQuoteGETRequest instead of SalesQuotePOSTRequest) and it returned the Quote entity including the OpportunityID custom field. Therefore the custom field plugin was working for that session.

If i restart the API service the problem goes away.

This reminds me of https://service.jiwa.com.au/servicedesk ... /JIWA-9388 that we've reported, but have been unable to reliably reproduce. In that issue, the problem was always fixed by restarting the API, was difficult to reproduce, and behaviour could vary based on user/token.


Do you have any ideas what I could do to troubleshoot?


We're running JIWA SR12 7.2.1
REST API 7.2.1.23
API Server is using the self hosted service behind reverse proxy.

Is the API service configured to log in with it's own unique Jiwa username?

Scott.Pearce wrote:Is the API service configured to log in with it's own unique Jiwa username?

Hi Scott,

The API Server is using the same user as the clients calling the API. Is that ok?

Joe.Thorpe wrote:The API Server is using the same user as the clients calling the API. Is that ok?

That's ok, provided the API is using a different windows account to anyone logging in to the same machine and logging into Jiwa with the same username.

We build a path based on Jiwa version, SQL Server name, Jiwa database name, Windows user name and Jiwa user name - and the conflict you are seeing suggests all of these things are the same for the API - AS WELL AS - another Jiwa process or instance.

You should also set the Exception Policy to Abort, so that if there a problem, it doesn't proceed so that you can't having missing custom fields.

Mike.Sheen wrote:

Joe.Thorpe wrote:The API Server is using the same user as the clients calling the API. Is that ok?

That's ok, provided the API is using a different windows account to anyone logging in to the same machine and logging into Jiwa with the same username.

We build a path based on Jiwa version, SQL Server name, Jiwa database name, Windows user name and Jiwa user name - and the conflict you are seeing suggests all of these things are the same for the API - AS WELL AS - another Jiwa process or instance.

You should also set the Exception Policy to Abort, so that if there a problem, it doesn't proceed so that you can't having missing custom fields.

Here's an example path that gave the error 'System.IO.IOException: The process cannot access the file': C:\ProgramData\Jiwa Financials\Jiwa 7\7.2.1\SYSTEM\x.x.x.x\SHAccsV7\Plugins\API\Runtime\Tie Insurance to Primary Web Order\Tie Insurance to Primary Web Order.dll'

The only enabled and running JIWA service is the Self Hosted API, and the service is set to logon as the Local system account.
No one besides me can access the API server, and if i ever login to the JIWA client on that server, i use my own user.

I'll change the exception policy, cheers!

Joe.Thorpe wrote:Here's an example path that gave the error 'System.IO.IOException: The process cannot access the file': C:\ProgramData\Jiwa Financials\Jiwa 7\7.2.1\SYSTEM\x.x.x.x\SHAccsV7\Plugins\API\Runtime\Tie Insurance to Primary Web Order\Tie Insurance to Primary Web Order.dll'

You should try to find out what the other process is that has the file open.

Mike.Sheen wrote:

Joe.Thorpe wrote:Here's an example path that gave the error 'System.IO.IOException: The process cannot access the file': C:\ProgramData\Jiwa Financials\Jiwa 7\7.2.1\SYSTEM\x.x.x.x\SHAccsV7\Plugins\API\Runtime\Tie Insurance to Primary Web Order\Tie Insurance to Primary Web Order.dll'

You should try to find out what the other process is that has the file open.

Oh, right. I'll have process explorer ready for the next time it happens. Cheers

Here's a potential workaround:

Configure the windows service to use it's own unique windows user account instead of "System".

Scott.Pearce wrote:Here's a potential workaround:

Configure the windows service to use it's own unique windows user account instead of "System".

Good point, i'll give it a shot. Thanks!

Scott.Pearce wrote:Here's a potential workaround:

Configure the windows service to use it's own unique windows user account instead of "System".

That's good advice for any windows service that may be accessed via the network. It allows security controls that don't apply to System. So even if someone manages to find an exploit in the service, you have a better chance of preventing carnage on your server.