You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jehu Jair RuizVillegas <Je...@amdocs.com.INVALID> on 2021/06/03 20:22:42 UTC
Issue while upgrading from Gemfire to Geode 1.13.2
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://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>
RE: Issue while upgrading from Gemfire to Geode 1.13.2
Posted by Jehu Jair RuizVillegas <Je...@amdocs.com.INVALID>.
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 <so...@amdocs.com>
Sent: Thursday, June 3, 2021 6:38 PM
To: Anilkumar Gingade <ag...@vmware.com>; dev@geode.apache.org
Cc: Jehu Jair RuizVillegas <Je...@amdocs.com>; dev-subscribe@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 <ag...@vmware.com>
Sent: Thursday, June 3, 2021 5:12 PM
To: dev@geode.apache.org
Cc: Soheb Khan <so...@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" <Je...@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>
RE: Issue while upgrading from Gemfire to Geode 1.13.2
Posted by Soheb Khan <so...@amdocs.com.INVALID>.
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 <ag...@vmware.com>
Sent: Thursday, June 3, 2021 5:12 PM
To: dev@geode.apache.org
Cc: Soheb Khan <so...@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" <Je...@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%7Csoheb.khan%40amdocs.com%7Cad5caa45f9814974490d08d926dcbd43%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637583551778881841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uZemeI7OkKuubEfI9O4HXV%2FSknpzJeQ%2FSHtl%2FkXUnns%3D&reserved=0 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amdocs.com%2Fabout%2Femail-terms-of-service&data=04%7C01%7Csoheb.khan%40amdocs.com%7Cad5caa45f9814974490d08d926dcbd43%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637583551778891837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s%2FgIZiPoCnCa0L9KWXsbdB3uWRQGyzOriB5JlW1H47g%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>
Re: Issue while upgrading from Gemfire to Geode 1.13.2
Posted by Anilkumar Gingade <ag...@vmware.com>.
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" <Je...@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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amdocs.com%2Fabout%2Femail-terms-of-service&data=04%7C01%7Cagingade%40vmware.com%7C2f2ed3398df64ff53b3508d926cef202%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637583492539678573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kTatOeY41purs0enpxdrFG0%2BgEvOoX%2BJKos2Jdt%2BzTg%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amdocs.com%2Fabout%2Femail-terms-of-service&data=04%7C01%7Cagingade%40vmware.com%7C2f2ed3398df64ff53b3508d926cef202%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637583492539678573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kTatOeY41purs0enpxdrFG0%2BgEvOoX%2BJKos2Jdt%2BzTg%3D&reserved=0>
RE: Issue while upgrading from Gemfire to Geode 1.13.2
Posted by Jehu Jair RuizVillegas <Je...@amdocs.com.INVALID>.
Hi guys
We build our code with Geode 1.4 and set the break point to out init function and we can see that is been called, and the Geode grid is coming up properly.
Below the stack trace of our code using Geode 1.4
[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)
If you have faces this issue or have any suggestion please let us know..
Thanks & regards.
From: Jehu Jair RuizVillegas
Sent: Thursday, June 3, 2021 3:23 PM
To: dev@geode.apache.org
Cc: Soheb Khan <so...@amdocs.com>
Subject: Issue while upgrading from Gemfire to Geode 1.13.2
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://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>