Structure to name deadlock.

Hi,

We are having difficulties with the structure to name functionnality in .NET on the server side. On some specific names (e.g. "THF"), the "importMol" function blocks (never go the next line, I suppose it is a deadlock), and increases the CPU load to 25% (quad core used), and never goes down. Obviously, it does not throw any exceptions.

The code is really simple.

 chemaxon.struc.Molecule jchemMolecule = chemaxon.formats.MolImporter.importMol(name, "name");
 decimal molarMass = (decimal)jchemMolecule.getMass();

This code never goes to the second line. It only appears on the webserver (this code is directly used in a WCF call, by only one user at a time). In the development webserver (in Visual Studio), it works. Our license currently limits the number of users accessing to the name to structure call to 1, but as only one server uses this license, is not multithreaded, and currently, only one user access the server at a time, the name to structure should work.

We are currently hosting the webserver on IIS 7.

 

Do you have any ideas how to remove this deadlock ?

Hi,

 

It seems more like a "live lock"  (endless loop), 25% is probably 1 of the 4 cores running on 100%.

This might be  general to naming, so I have moved this to the naming forum section for now.

(maybe too soon, but we'll see ...)

Could you please provide the exact JChem library version in case of both the "good" and "bad" server ?

 

Best regards,

Szilard

 

Hello,

we are investigating the problem and get back as soon as possible.

Best regards,

Gabor Vasko

Szilard wrote:

Could you please provide the exact JChem library version in case of both the "good" and "bad" server ?

 

On both our development test webserver and on IIS, we use the 5.3.6.30 JChem.dll.

 

Thank you for your answers and investigations.

Hi,

 

Do you have any news or suggestions about the resolution of this problem ?

 

Best regards,

JC

Hi,

 

Do you have any news ? It has been a while now, and we are waiting for your answers to start the production server.

 

Best regards,

JC

Hi,

I have managed to reproduce your problem using JChem API 5.3.6.30 but I wasn't able to reproduce it with our latest JChem API (5.4.1.1062). I have tested on Windows 2008 R2 X64 server with .NET 4.0 set for application pool.

Can you test it with our latest  .NET API?

Calin.

Hi,

I have tried with the latest version and it works. We will try to update our chemaxon version.

 

Thank you for your investigations.

JC

After updating our chemaxon version (to 5.4.1.1) on our production servers, the problem is still here. THF still cannot be converted from name to structure.

Hi,

I have tried multiple scenarios for 5.4.1.1062 under IIS 7 with OS Windows 2008 R2 x64 but I couldn't reproduce the problem...

Can you give us more details about your production servers?

We would like to know:

1. What operating system you have?

2. What IIS?

3. What .NET framework version is set for application pool (2.0 or 4.0?).

4. Managed Pipeline  Mode for application pool?

5. Identity for application pool (what is the user used for your application pool?).

6. Does that user (which is used for application pool) has read rights folder where license file is located?

7. Is "Enable 32-bit Applications" option set to True or False for your application pool?

 8. Could you also create a diagnostic page to make sure that JChem.dll version 5.4.1.1062 is loaded in your IIS worker process?

I created the following code you could use:

 

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using chemaxon.struc;

using chemaxon.formats;

using chemaxon.license;

using System.Diagnostics;

 

public partial class _Default : System.Web.UI.Page 

{

    protected void Page_Load(object sender, EventArgs e)

    {

        LicenseHandler.getInstance().setLicenseFile(@"c:\chemaxon\license.cxl");

        string mrvMol = MolImporter.importMol("benzene", "name").toFormat("MRV");

 

        Process currentProcess = Process.GetCurrentProcess();

        foreach (ProcessModule loadedModule in currentProcess.Modules)

        {

            if (loadedModule.ModuleName.ToLower() == "jchem.dll")

            {

                Response.Write("Loaded Jchem: "+ loadedModule.FileVersionInfo.FileVersion.ToString()+"<br/>");

            }

        }

    }

}

The root of the issue is a bug inside the .NET 4 CLR Optimizer. Microsoft is aware of the bug, though no fix officially known to be released.

It can be avoided by using older frameworks.

https://connect.microsoft.com/VisualStudio/feedback/details/566946/x64-jit-optimization-bug

Or, substituting the code with a different one, where the optimizer fails. (We changed the implementation of jaja.lang.Long.trailingZeroes() and the problem ceased to exist.)