In addition to marking LOG as @transient, I also made it lazy val so that it does not result in initialization order issues.
Regards, Neeraj -------------------------------------------- On Wed, 4/4/18, Neeraj Vaidya <[email protected]> wrote: Subject: Re: Failing to deploy service To: "Denis Mekhanikov" <[email protected]> Cc: [email protected] Date: Wednesday, 4 April, 2018, 10:50 AM Hi Denis, By making the Logger a part of the companion object, it works. However, it also works if I keep the LOG field part of the Service implementation class but annotate it as @transient. Regards, Neeraj -------------------------------------------- On Wed, 4/4/18, Denis Mekhanikov <[email protected]> wrote: Subject: Re: Failing to deploy service To: "Neeraj Vaidya" <[email protected]> Cc: [email protected] Date: Wednesday, 4 April, 2018, 9:19 AM Neeraj, Thanks for sharing the details!I'll try to reproduce this issue. If you put a logger into a field of the service class, it will be serialized together with the service, which doesn't make much sense.You should make the logger a part of a companion object, so it won't be sent over network. Denis ср, 4 апр. 2018 г. в 12:02, Neeraj Vaidya <[email protected]>: Hi Denis, Thanks for your responses. Here is the class I am using. It is also there in github : https://github.com/en-vee/axlrate/blob/axlrate-release-1/axlrate/axlrate-charging/src/main/scala/org/hypercomp/axlrate/charging/loader/AxlRateChargingService.scala When I comment out the LOG member and replace all debug statements with println statements, it works fine. It appears that this is causing the difference. The LOG member is just a wrapper over some Log over slf4j/logback API. And it in turn contains a member called "marker". package org.hypercomp.axlrate.charging.loader import org.hypercomp.axlrate.utils.imdg.AxlRateImdgIgniteService import org.hypercomp.axlrate.core.logging.AxlRateLogger import org.hypercomp.axlrate.utils.imdg.AxlRateImdgMessage class AxlRateChargingService() extends AxlRateImdgIgniteService[AxlRateImdgMessage] { val LOG = AxlRateLogger(classOf[AxlRateChargingService]) override val execute:()=>Unit = () => { LOG.process.debug("Starting execute method") } override val initialize:()=>Unit = () => { LOG.process.debug("Initializing.....") } override val cancel:()=>Unit = () => { LOG.process.debug("Stopping service") } } Regards, Neeraj -------------------------------------------- On Wed, 4/4/18, Denis Mekhanikov <[email protected]> wrote: Subject: Re: Failing to deploy service To: [email protected] Date: Wednesday, 4 April, 2018, 7:43 AM Neeraj, There is no such restriction, as far as I know.What do you mean by "using"? Could you provide this class? Denis ср, 4 апр. 2018 г. в 10:32, Neeraj Vaidya <[email protected]>: On analysing further it seems the field id indicated as “marker” below is actually a member of one of the class instances used inside the service classes. Is there anything restriction as such about using custom classes in a service implementation ? Sent from my iPhone > On 4 Apr 2018, at 15:06, Neeraj Vaidya <[email protected]> wrote: > > Hi, > > I am trying to deploy a service during ignite node startup. But I noticed 2 peculiar behaviours. I am loading the class using > Note that I am using a single-node cluster. Thus, the service class is present on the classpath of the node where I am trying to deploy this service. > > Observation-1 > --------------------- > When the service class is part of the same (scala) package as the class which contains the main method and also starts the ignite cluster, the service gets deployed successfully. > > Observation-2 > ------------------- > However, when the service class is NOT part of the same (scala) package as the class which contains the main method and also starts the ignite cluster, the service DOES NOT deployed successfully. > > I am providing the user the ability to configure the Service class via a configuration file i.e. the configuration file will contain an entry which will contain a key : > serviceClass = "org.hypercomp.axlrate.charging.loader.AxlRateChargingService" > serviceName = "AXLRATE_CHARGING_MODULE" > ... > ... > > Then in the scala code, I am instantiating the service class above using Class.forName(serviceClass).newInstance.asInstanceOf[....] Not sure if this is a great idea, but it works when the class is part of the same package as the class containing the main(args: Array[String]) method. > > The stack trace I see is as follows [Note all classes prefixed with org.hypercomp are my custom classes]. : > > [14:12:54,906][SEVERE][main][GridServiceProcessor] Failed to marshal service with configured marshaller [name=AXLRATE_CHARGING_MODULE, srvc=org.hypercomp.axlrate.charging.loader.AxlRateChargingService@b91d8c4, marsh=o.a.i.i.binary.BinaryMarshaller@6ea1bcdc] > class org.apache.ignite.IgniteCheckedException: Duplicate field ID: marker > at org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:9883) > at org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:534) > at org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:568) > at org.apache.ignite.internal.IgniteServicesImpl.deployAll(IgniteServicesImpl.java:238) > at org.apache.ignite.internal.IgniteServicesImpl.deploy(IgniteServicesImpl.java:221) > at org.hypercomp.axlrate.utils.imdg.AxlRateImdgManager$AxlRateIgniteImdgManager$.$anonfun$startNode$1(AxlRateImdgManager.scala:80) > at org.hypercomp.axlrate.utils.imdg.AxlRateImdgManager$AxlRateIgniteImdgManager$.$anonfun$startNode$1$adapted(AxlRateImdgManager.scala:80) > at scala.collection.immutable.List.foreach(List.scala:389) > at org.hypercomp.axlrate.utils.imdg.AxlRateImdgManager$AxlRateIgniteImdgManager$.startNode(AxlRateImdgManager.scala:80) > at org.hypercomp.axlrate.utils.imdg.AxlRateImdgManager$.startNode(AxlRateImdgManager.scala:115) > at org.hypercomp.axlrate.core.loader.AxlRateBoot$.main(AxlRateBoot.scala:92) > at org.hypercomp.axlrate.core.loader.AxlRateBoot.main(AxlRateBoot.scala) > Caused by: class org.apache.ignite.binary.BinaryObjectException: Duplicate field ID: marker > at org.apache.ignite.internal.binary.BinaryClassDescriptor.<init>(BinaryClassDescriptor.java:312) > at org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:780) > at org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752) > at org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623) > at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164) > at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147) > at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134) > at org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496) > at org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160) > at org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663) > at org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
