Hi guys
It's seems that we some BWC issue in Geode 1.13.2, what we understand after our
investigation that in Geode 1.13.2 when the cache XML is parsed it is
constructing the classes in a different order.
In earlier version (Geode 1.4), it seems when parsing the cache XML, the
classes were constructed from top to bottom, now since the order is changed few
of the singleton classes that we were initializing/constructing in the entry
function of Declarable interface were not initialized.
Now during the construction of service functions we were using these singleton
classes to do some operations, so we have to refactor our code accordingly. Now
the problem it's fixed and servers are up and running.
Thanks & regards.
-----Original Message-----
From: Soheb Khan <soheb.k...@amdocs.com>
Sent: Thursday, June 3, 2021 6:38 PM
To: Anilkumar Gingade <aging...@vmware.com>; dev@geode.apache.org
Cc: Jehu Jair RuizVillegas <jehu-jair.ruiz-ville...@amdocs.com>;
dev-subscr...@geode.apache.org
Subject: RE: Issue while upgrading from Gemfire to Geode 1.13.2
Hi Anil,
We are using enterprise version of Gemfire, below are the details of gemfire
server.
GemFire product directory: /opt/gemfire_server-8.2.3.0
Java version: 8.2.3 build 18378 02/16/2017 09:55:11 PST javac 1.7.0_79
Native version: 6.5 06/02/2010 11:16:48 PDT optimized i386 Linux 2.4.21-47.EL
We have already upgrade few accounts from gemfire to Geode, during that upgrade
we used Geode 1.4 to compile our code, we didn’t have to do any code changes,
build and link it with Geode Jars.
Everything worked fine and its already running in production,
But now we are trying to upgrade to newer version of Geode 1.13.2 and we are
facing the problem.
We can see declarable interface of cache xml is calling our initializer during
start up in Geode 1.4 but same is not working in Geode 1.13.2, is the any
change in implementation ? any idea ?
[1] amdocs.imdg.initializations.Startup.init (Startup.java:67)
[2] org.apache.geode.internal.cache.xmlcache.CacheXmlParser.createDeclarable
(CacheXmlParser.java:1,964)
[3] org.apache.geode.internal.cache.xmlcache.CacheXmlParser.createDeclarable
(CacheXmlParser.java:1,925)
[4] org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endDeclarable
(CacheXmlParser.java:2,609)
[5] org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement
(CacheXmlParser.java:3,020)
[6]
org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement
(CacheXmlParser.java:3,416)
[7] com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement
(AbstractSAXParser.java:610)
[8] com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement
(XMLSchemaValidator.java:934)
[9]
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement
(XMLDocumentFragmentScannerImpl.java:1,784)
[10]
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
(XMLDocumentFragmentScannerImpl.java:2,969)
[11] com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
(XMLDocumentScannerImpl.java:605)
[12] com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
(XMLNSDocumentScannerImpl.java:113)
[13]
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
(XMLDocumentFragmentScannerImpl.java:507)
[14] com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(XML11Configuration.java:867)
[15] com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(XML11Configuration.java:796)
[16] com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
(XMLParser.java:142)
[17] com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
(AbstractSAXParser.java:1,216)
[18]
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
(SAXParserImpl.java:644)
[19] com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse
(SAXParserImpl.java:328)
[20] javax.xml.parsers.SAXParser.parse (SAXParser.java:196)
[21] org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse
(CacheXmlParser.java:224)
[22] org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml
(GemFireCacheImpl.java:4,309)
[23]
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache
(GemFireCacheImpl.java:1,403)
[24] org.apache.geode.internal.cache.GemFireCacheImpl.initialize
(GemFireCacheImpl.java:1,203)
[25] org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate
(GemFireCacheImpl.java:778)
[26] org.apache.geode.internal.cache.GemFireCacheImpl.create
(GemFireCacheImpl.java:764)
Thanks,
Soheb
-----Original Message-----
From: Anilkumar Gingade <aging...@vmware.com>
Sent: Thursday, June 3, 2021 5:12 PM
To: dev@geode.apache.org
Cc: Soheb Khan <soheb.k...@amdocs.com>
Subject: Re: Issue while upgrading from Gemfire to Geode 1.13.2
Can you be more specific about the GemFire version; Is it a
supported/enterprise GemFire version? As for as I know Geode community has
never tried upgrading a GemFire version to Geode.
On 6/3/21, 1:34 PM, "Jehu Jair RuizVillegas"
<jehu-jair.ruiz-ville...@amdocs.com.INVALID> wrote:
Hi team
We upgrading from Gemfire to Geode 1.13.2, this is mostly a technical
upgrade and we are facing some exception while trying to bring up JVMs, below
the exception:
Exception in thread "main" java.lang.ExceptionInInitializerError
at
amdocs.imdg.statistics.LatencyManagerFactory.getLatencyManager(LatencyManagerFactory.java:20)
at
amdocs.imdg.functions.GetRTNotifications.<clinit>(GetRTNotifications.java:33)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:201)
After investigation using jdb, we found that one of the classes that was
supposed to be initialized during the initialization process at the start up of
JVM was not called,
<entry>
<key>
<string>1</string>
</key>
<value>
<declarable>
<class-name>amdocs.imdg.initializations.Startup</class-name>
</declarable>
</value>
</entry>
This is how our cache.xml is defined, this Startup class is not been called
when upgrading to Geode. We set some break points in the startup's constructor
an is not been called.
Thanks & regards.
This email and the information contained herein is proprietary and
confidential and subject to the Amdocs Email Terms of Service, which you may
review at
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amdocs.com%2Fabout%2Femail-terms-of-service&data=04%7C01%7CJehu-Jair.Ruiz-Villegas%40amdocs.com%7C37453f52e83f464fe55608d926e8b04c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637583603100664678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WbEGZjWNScjjOVWeO5%2FDVwLUbXXap9H5pQ%2FYVzOJOc%3D&reserved=0
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amdocs.com%2Fabout%2Femail-terms-of-service&data=04%7C01%7CJehu-Jair.Ruiz-Villegas%40amdocs.com%7C37453f52e83f464fe55608d926e8b04c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637583603100664678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WbEGZjWNScjjOVWeO5%2FDVwLUbXXap9H5pQ%2FYVzOJOc%3D&reserved=0>
This email and the information contained herein is proprietary and confidential
and subject to the Amdocs Email Terms of Service, which you may review at
https://www.amdocs.com/about/email-terms-of-service
<https://www.amdocs.com/about/email-terms-of-service>