CODEWITHSUNDEEP
javagemfiregeode
Seb
Seb

Reputation: 1

Apache Geode and IBM Java

We are currently testing Apache Geode across a couple of platforms on Linux along with different Java distributions. A problem has occurred with using IBM Java in that both the startup and performance is very (to say the least) poor. The configuration across the systems is the same yet when we try to run it on the x86 platform under RedHat we cannot even manage to get Geode to start properly.

A locator is first started however no up message is received in the GFSH CLI interface, just a continuous stream of '.' but by viewing the log it is possible to determine when it has started and enter CTRL+C so that it is possible to continue.

Starting a server produces similar problems but more times than often the server will never start. If you do eventually manage to get it to start, after many attempts, then it will more than likely crash once you start to stress it with a workload.

The following extracts from logs show different types of errors:

com.ibm.tools.attach.AttachNotSupportedException: Target no longer available at com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:369) at com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94) at com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37) at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231) ... The Cache Server process terminated unexpectedly with exit status 1. Please refer to the log file in /home/geode/server1 for full details.

Note: it is not possible to view the log as one is never created!

Exception in thread "main" com.gemstone.gemfire.InternalGemFireError: Did not expected a java.lang.StringBuffer on top of the stack. at com.gemstone.gemfire.internal.Assert.throwError(Assert.java:91) at com.gemstone.gemfire.internal.Assert.assertTrue(Assert.java:115) at com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.endRegionAttributes(CacheXmlParser.java:1449) at com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3190) at com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3726) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) ...

Having had a quick look through the source code it seems that IBM Java is not that well supported and I think that this message in a successful startup of a locator supports that:

Java version older than 1.7.0_72. Minimum system requirements not met. Unexpected behavior may result in additional errors.

Apart from the errors above, when we have managed to get it working on other hardware and OS'es the performance is very poor and the transaction (TPS) rate is pretty abysmal.

My question is basically, has anyone successfully used Geode with IBM Java and if so, what did you do to get it working?

Please ask if more information is required, thanks.

Okay, here's a bit more information:

Feel free to ask for more information or I can attempt more tests with various configuration/parameter changes, thanks.

Upvotes: 0

Views: 411

Answers (2)

Darren Foong
Darren Foong

Reputation: 113

I encountered the same problem; I suspect that Geode is (currently) incompatible with the official Apache Xerces implementation (that IBM Java uses).

I've already filed a JIRA issue (https://issues.apache.org/jira/browse/GEODE-3306) containing results from my little investigation.

Workarounds for you now:

  1. Remove the non-essential ("ignorable") whitespace in your cache.xml files (and sacrifice readability).
  2. Download the Oracle JDK internal Xerces implementation (http://central.maven.org/maven2/com/sun/xml/parsers/jaxp-ri/) with which Geode is compatible.

Upvotes: 0

Swapnil
Swapnil

Reputation: 1301

To narrow down if this problem is with IBM jdk or gfsh, can you please try to programmatically start the cache servers? For e.g the following will start a server with an embedded locator:

CacheFactory cf = new CacheFactory();
cf.set("start-locator", "localhost[10334]");
Cache cache = cf.create();
cache.addCacheServer();

From the other processes, you can point to the locator above.

CacheFactory cf = new CacheFactory();
cf.set("locators", "localhost[10334]");
Cache cache = cf.create();
cache.addCacheServer();

Upvotes: 0

Related Questions