【问题标题】:Why is ignite failing to deserialize a GridClosureProcessor object?为什么 ignite 无法反序列化 GridClosureProcessor 对象?
【发布时间】:2019-04-09 01:56:21
【问题描述】:

我知道其他人已经发布了类似的堆栈。我的问题是“看起来 Ignite 正试图反序列化一个 GridClosureProcessor(或它的闭包?)。如果是这样,为什么要这样做?我试图从根本上导致这个问题,但我的代码都没有在堆栈中,除了MyCallable 在顶部提到(实际上不在堆栈中)。

除非它们是内部的,否则此代码路径中不会发生缓存放置。我之所以提到这一点,是因为另一篇文章的评论说“未知对”可能是由错误类型的缓存放置引起的。

我专注于

无法反序列化对象 [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2]

剩下的就到这里了。

[2019-04-08 22:20:23,724][ERROR][pub-#63][GridJobWorker] 失败 初始化作业 [jobId=800890ff961-7ff6a786-9d4d-43d8-91a0-70225c5e3a4a, ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=com.obfucorp.aa.project.core.jobs.MyCallable, dep=GridDeployment [ts=1554761996013,depMode=SHARED, clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6, clsLdrId=730290ff961-8d93b961-09f2-48c3-bd2f-49db31aae61e, userVer=0, 位置=真, sampleClsName=o.a.i.i.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1, pendingUndeploy=false,未部署=false,usage=1], taskClsName=com.obfucorp.aa.project.core.jobs.MyCallable, sesId=700890ff961-7ff6a786-9d4d-43d8-91a0-70225c5e3a4a, 开始时间=1554762023663,结束时间=9223372036854775807, taskNodeId=7ff6a786-9d4d-43d8-91a0-70225c5e3a4a, clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,关闭=假, cpSpi=null,failSpi=null,loadSpi=null,usage=1,fullSup=false, 内部=假,topPred=null, subjId=7ff6a786-9d4d-43d8-91a0-70225c5e3a4a, mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null, 哈希=314803578]],execName=null], jobId=800890ff961-7ff6a786-9d4d-43d8-91a0-70225c5e3a4a]] 类 org.apache.ignite.IgniteCheckedException:无法反序列化对象 [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2] 在 org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9908) 在 org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:438) 在 org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1117) 在 org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921) 在 org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555) 在 org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183) 在 org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) 在 org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 在 java.lang.Thread.run(Thread.java:748) 引起:类 org.apache.ignite.binary.BinaryObjectException:反序列化失败 目的 [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2] 在 org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:875) 在 org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762) 在 org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714) 在 org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310) 在 org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99) 在 org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82) 在 org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9902) ... 10 更多原因:类 org.apache.ignite.binary.BinaryInvalidTypeException:未知对 [platformId=0, typeId=-1409390795] 在 org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:696) 在 org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755) 在 org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714) 在 org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1799) 在 org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1329) 在 org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.readBinary(GridClosureProcessor.java:1872) 在 org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:834) ... 16 更多原因:java.lang.ClassNotFoundException:未知对 [platformId=0, typeId=-1409390795] 在 org.apache.ignite.internal.MarshallerContextImpl.getClassName(MarshallerContextImpl.java:385) 在 org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:335) 在 org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:687) ... 22 更多

更新 - 想指出这是一个全新的部署。周围没有旧文件或保留任何东西。所有类要么是从偶数中提取的,要么是新编译的。太棒了。

Pavel,这是(Scala)代码(已编辑)

object MyCallable {
    type FooList = Array[Foo]
}

class MyCallable(cacheName: String) extends IgniteCallable[FooList] with Serializable with LazyLogging {
    @IgniteInstanceResource
    private var ignite: Ignite = _

    override def call(): FooList = {
        logger.debug("callable called.");
        val fooCache = ignite.getOrCreateCache[String, Foo](cacheName)
        val qry = new ScanQuery[String, Foo]()
        qry.setLocal(true)
        val cursor = fooCache.query(qry)
        val ret = cursor.iterator().asScala.map(e => e.getValue).toArray
        logger.info("load status array: {}", ret.mkString)
        return ret
    }

    @IgniteInstanceResource
    def setIgnite(ignite: Ignite): Unit = {
        this.ignite = ignite
    }
}

【问题讨论】:

  • 请显示 com.obfucorp.aa.project.core.jobs.MyCallable 类
  • 已编辑帖子以添加课程代码。

标签: ignite


【解决方案1】:

Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair [platformId=0, typeId=-1409390795]

您好像丢失了编组器缓存 (marshaller/ dir)。

您可以执行一次ignite.marshaller().marshal(new WhateverTypeIsCausingThis()); 以消除此错误。

【讨论】:

  • 我在 ignite 上看不到该方法,所以我这样做了。 val gkc: GridKernalContext = (ignite.asInstanceOf[IgniteKernal]).context() val marshaller = gkc.grid().configuration().getMarshaller 但是,它没有帮助。我不确定实际上是哪种类型导致了这种情况。它在堆栈中并不明显,除非它是“org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2]”。
  • 我查看了服务器节点。该目录在那里并且只包含/var/lib/ignite/work/marshaller/902610168.classname0。这个单一文件的内容是一个字符串,“javax.cache.integration.CacheLoaderException”。这是预期的吗? (此时代码中我们还没有加载任何缓存。)这意味着什么吗?
  • 你有坚持吗?如果答案是肯定的,这意味着您丢失了编组器缓存。您应该始终将工作/编组器与持久数据放在一起。
  • 是的,我们确实有持久性。我们在启动所有新内容后立即收到此错误(因此在启动之前实际上没有保留任何内容)。问题:(1)那时(这么早)我们怎么可能丢失了编组器缓存? (2) 我们需要在启动时显式创建它吗?我不确定它曾经在那里。 (3) 如您所说,我需要做些什么才能使工作/编组器与持久数据保持一致。我不知道该采取什么行动。
  • 我猜你之前的运行有剩余数据(但没有编组缓存),Ignite 不知道这个数据映射到什么类型。
猜你喜欢
  • 2014-07-30
  • 1970-01-01
  • 2016-12-30
  • 2016-10-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多