Corrupted Images in Ajax Example

Hello,

I am currently learning how to use JChem web services and Ajax integration. I am using web services 5.3.0.2

I've successfully deployed and tested the Ajax sample app (/tomcat/webapps/ROOT/ajax/) on our local development server. A deployment using idential data on a remote server using identical data does not seem to work properly. The images produced by the example application appear to be corrupted.

This is the version of Java I am running on our development server:

java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_14-b03, mixed mode)

On my remote production server:

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

Attached is a screenshot of the garbled images. Note that when I click on an image, the corrupted image is replaced by the expected correct one. That's why the image with ID "2" appears to be correct.

I know that any version of Java 1.5 or later should be supported. However, might there be a Java-related issue here after all.

I think I can rule out data corruption since I am using identical data sets that successfully passed a "jcman r" execution with no errors.

Any ideas?

Thanks,

-John David

John,

I suspect this wrong molecule visualization (the implementation can be found inside jsp/img.jsp) is because Marvin does not find the proper character set it needs. Thus, I forward your question to a Marvin developer, who knows this area much better than me.

Regards,

Roland

As I see, the atom labels does not display fine on the generated images. I assume that Java did not draw text with the default font on server side.

Probably, the java.headless jvm parameter is missing. See the linking topic about it.

https://www.chemaxon.com/forum/ftopic73.html

If it is already defined and the problem still exists, check that you can create image into file on server side with Marvin Beans / Jchem api. If the generated image file is correct, the problem may be in the transmission between the server and the local browser.

John David,

To try if this works with your system, you can add -D java options to the <JChemWebServices_dir>/bin/startup.sh file. 

For example,

JAVA_OPTS='-Djava.awt.headless=true -Xmx256M'
export JAVA_OPTS

Jon

Hi All,

Thanks for your help with this.

I modified my JAVA_OPTS and restarted the services as jlee suggested:

JAVA_OPTS='-Djava.awt.headless=true -Xmx256M'
export JAVA_OPTS

I ran both the Ajax example /examples/php/imggen.php to test the results.

I continue to see garbled characters in both Ajax and imggen.php.

Any ideas?

Thanks,

-John David

It may be a platform specific issue. Probably, certain fonts are not implemented properly in 64bit Java for your platform.

I recommend to test image generator JSP code with a 32bit Java on your remote server, where font issue has appeared.

Hi Tamas,

Thanks for your suggestion. Both my development and production servers are 64 bit machines.

development:

$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_14-b03, mixed mode)

production:

$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

The difference between the two is the specific build version. Have you all tested this build version for 64 bits with Web Services? If so, have you encountered font issues?

I can see if the production server administrators can install an identical version of Java as the one on the development server. Any other ideas?

-John David

Hi All,

The administrators that manage the production server have installed a 1.5.X version of Java:

$ java -version
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)

I ran "jcman r" to make sure JChem continues to work correctly with this different version of Java. No errors were reported.

However, output continues to be garbled in an identical way.

I am stuck and unable to proceed with the project until this issue is resolved. Can you think of anything else I should try?

I would really appreciate it.

-John David

John David,

Thank you for your patience.  We have tested Web Services when using 64 bit Java as well as Linux distributions.   It is only a guess, but the lack of a display may be causing issues.  Is there any more information you can tell us about the configuration or other attempts to solve the issue?

I know you may have mentioned it before, but can you please tell us the version of Linux you are using when experiencing this problem?  

Is it possible to install a 32 bit java and test it to eliminate this as a problem?

Jon

Hi Jon,

Thanks for your help.

I am using CentOS 5.4 hosted inside a virtual machine.

$ uname -a
Linux xxxxxxx.com 2.6.18-028stab060.8 #1 SMP Mon Feb 9 20:25:36 MSK 2009 x86_64 x86_64 x86_64 GNU/Linux

The OS runs on dual quad-core Xeon processors and has 3GB of RAM available.

I'll see if it is possible to install 32 bit Java. Can you think of any other way to work around the lack of display possibly causing issues? Do you know if Java depends on some external source for font information? Maybe this source is present on my development machine but not the production server?

Thanks again for your help,

-John David

Are you sure that you use a Sun distributed Java version?

We do not support non-Sun distros.

Which Java versions are supported by Marvin.

Hi Tamas,

Yes, I am very sure that I am using a Sun distribured Java version:

$ java -version
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)

Can you think of anything else that might be causing a problem beside possibly a 64-bit virtual machine as opposed to a 32-bit vm? I am currently unable to deliver a project built using JChem Webservices because of this garbled text.

Thanks,

-John David

John David,

We are still working on this problem. 

 

Have you tried the alternative found in this post?

https://www.chemaxon.com/forum/ftopic73.html

 

I also found a webpage suggesting running "export DISPLAY=:0.0" as a possible solution:

http://www.linuxforums.org/forum/linux-newbie/143095-no-x11-display-variable-what-does-mean.html

 

Do any one these help?

 

Jon

John David,

While we have tested in Java 1.6, it is a difference between your dev and production machines.  One thought I had was to upgrade to or install a new java version to 1.6 on the dev machine and see if this reproduces the problem. 

 

Also, is your dev machine also "remote"?  Can you explain more about what you mean.  Does the dev machine have a monitor attached?

Hi jlee, thanks for your help. Sorry for the late reply.

Our dev machine is a Debian Etch machine with a monitor but no X windows system installed. I built and configured this system at our office a few years ago. There is no GUI whatsoever on this machine. Here is the version of Java running on this system:

java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_14-b03, mixed mode)

The production server is a VPS account hosted remotely at inmotionhosting.com. It runs CentOS with no X windows system installed. I've tested this application and have had garbled characters appear using both Java 1.6 and 1.5. Here is current version of Java running on this system:

java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)

Is it possible that perhaps Java depends on some external packages or libraries for character support? It may be the case that they are available by default on my development server but not my production server. If you have any Java experts in your staff, forward them this issue. They may be able to help.

Thanks,

-John David

John David,

 

Taking an exceprt from:

http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#desktop-rendering

 

---

 

 

What are font configuration and font.properties files?

The font configuration files are used in Sun's JREs since 5.0 to map logical font names to physical fonts; earlier versions used font.properties files. There are several files to support different mappings depending on the host operating system version. The files are located in the lib directory within the JRE installation.

Note that font configuration and font.properties files are implementation dependent. Not all implementations of the Java platform use them, and the format and content vary between different runtime environments as well as between releases.

 

---

 

Can you please post the "fontconfig.properties.src" from your jre's lib directory of both the dev and production machines?

Please also include and any other fontconfig.XXX.properties.src that are relevant to your operating system. 

John David,

We are using sans-serif plain for the atom labels.

 

If it is indeed a font issue, perhaps this FAQ will help to install missing fonts on your Debian server.

http://wiki.debian.org/Fonts/FAQ

 

Please let us know if this works for you.

 

Jon

Hi jlee,

Thanks for your reply. I'm currently reading the information you provided to see if I can find a resolution to my problem.

I've attached the fontconfig.properties.src and fontconfig.OS.properties.src that I think may be getting read by the system.

Please recall that our production server is the one exhibiting corrupted character issues. This is a CentOS server.

Our development server, a Debian server, works just fine.

Please take a look at these files and let me know if you notice any problems.

John David,

I don't notice any problems, but I'm not an expert in this area.  

I would check that the filenames described in the fontconfig files do exist and are valid.  

Especially, 

sansserif.plain.latin-1=DejaVu LGC Sans

filename.DejaVu_LGC_Sans=/usr/share/fonts/dejavu-lgc/DejaVuLGCSans.ttf

 

sansserif.plain.latin-1=DejaVu Sans

filename.DejaVu_Sans=/usr/share/fonts/dejavu/DejaVuSans.ttf

Hi Jon,

We've taken a look at the file names as you suggested. We did find a possible issue with our system configuration. Specifically, the lack of a /usr/share/fonts/dejavu/ directory.

We installed those missing fonts, ran "fc-cache /usr/share/fonts/dejavu/" on that directory, and made sure that our paths are pointing to the missing fonts correctly. This still has not resolved our issue.

> I don't notice any problems, but I'm not
an expert in this area. 

Might it be possible to contact a developer that has worked with Linux installs of Marvin tools? Maybe they could help with this issue? We won't be able to deliver the system we are building until this particular issue is fixed. We are working against a hard deadline and getting this resolved quickly is essential.

Thanks,

-John David

John David,

I'm sorry, but I checked with our developers familiar with Linux and they have not encountered this error and will not be able to help. 

My suggestion would be to search through or post to other Linux/Java forums for answers. 

If you find the source of the problem, it will be helpful for others to share the result here as well.

 

Sincerely,

Jonathan Lee