Corda не может выполнить простой поток с «Исключением во время сканирования», вызванным OOM пространства кучи Java - PullRequest
Новая
       8

Corda не может выполнить простой поток с «Исключением во время сканирования», вызванным OOM пространства кучи Java

0 голосов
/ 28 февраля 2019

Работает нормально в Corda 3.3, но не работает в Corda 4.0

Узел правильно встает, а затем, когда я вызываю первый очень простой поток - происходит эта ошибка.

Я пытался запустить узел с 2048пространство кучи, но безуспешно.

Stacktrace:

java.lang.RuntimeException: java.util.concurrent.ExecutionException: исключение при сканировании в io.github.classgraph.ClassGraph.scan(ClassGraph.java:1153) ~ [classgraph-4.6.12.jar: 4.6.12] на io.github.classgraph.ClassGraph.scan (ClassGraph.java:1173) ~ [classgraph-4.6.12.jar: 4.6.12] в io.github.classgraph.ClassGraph.scan (ClassGraph.java:1185) ~ [classgraph-4.6.12.jar: 4.6.12] в net.corda.core.internal.ClassGraphUtilsKt.pooledScan (ClassGraphUtils.kt:18) ~ [corda-core-4.0.jar :?] в net.corda.core.internal.ClassLoadingUtilsKt.createInstancesOfClassesImplementing (ClassLoadingUtils.kt: 22) ~ [corda-core-4.0.jar :?] в net.corda.core.serialization.internal.AttachmentsClassLoaderBuilder $ withAttachmentsClassloaderContext $ serializationContext $ 1.apply (AttachmentsClassLoader.kt: 316) ~ [corda-core-4.0.jar :?] в net.corda.core.serialization.internal.AttachmentsClassLoaderBuilder $ withAttachmentsClassloaderContext $ serializationContext $ 1.apply (AttachmentsClass):[corda-core-4.0.jar :?] в java.util.HashMap.computeIfAbsent (HashMap.java:1127) ~ [?: 1.8.0_191] в java.util.Collections $ SynchronizedMap.computeIfAbsent (Collections.java:2672)) ~ [?: 1.8.0_191] в net.corda.core.serialization.internal.AttachmentsClassLoaderBuilder.withAttachmentsClassloaderContext (AttachmentsClassLoader.kt: 313) ~ [corda-core-4.0.jar :?] в net.corda.core..internal.AttachmentsClassLoaderBuilder.withAttachmentsClassloaderContext $ default (AttachmentsClassLoader.kt: 310) ~ [corda-core-4.0.jar :?] в net.corda.core.transactions.LedgerTransaction.internalPrepareVerify ~ 135 [транзакция $: L (corda-core-4.0.jar :?] на net.corda.core.transactions.LedgerTransaction.verify (LedgerTransaction.kt: 125) ~ [corda-core-4.0.jar :?] на net.corda.core.transactions.TransactionBuilder.addMissingDependency (TransactionBuilder.kt: 173) ~ [corda-core-4.0.jar :?] в net.corda.core.transactions.TransactionBuilder.toWireTransactionWithContext $ core (TransactionBuilder.kt: 160 ~))-4.0.jar :?] at net.corda.core.transactions.TransactionBuilder.toWireTransactionWithContext $ core $ default (TransactionBuilder.kt: 128) ~ [corda-core-4.0.jar :?] в net.corda.core.transactions.TransactionBuilder.toWireTransaction (TransactionBuilder.kt: 125) ~ [corda-core-4.0.jar :?] at net.corda.core.transactions.TransactionBuilder.toLedgerTransaction (TransactionBuilder.kt: 451) ~ [corda-core-4.0.jar :?] at net.corda.core.transactions.TransactionBuilder.verify (TransactionBuilder.kt: 459) ~ [corda-core-4.0.jar :?] at com.insettle.core.corda.flows.abstractions.AbstractInitiatingFlow.call (AbstractInitiatingFlow.kt: 60) ~ [?:?] на com.insettle.core.corda.flows.abstractions.AbstractInitiatingFlow.call (AbstractInitiatingFlow.kt: 12) ~ [?:?] на net.corda.node.services.statemachine.FlowStateMachineImpl.run (FlowStateMachineImpl.kt: 228) ~ [corda-node-4.0.jar :?] в net.corda.node.services.statemachine.FlowStateMachineImpl.run (FlowStateMachineImpl.kt: 45) ~ [corda-node-4.0.jar :?] в co.paralleluniverse.fibers.Fiber.run1 (Fiber.java:1092) ~ [quasar-core-0.7.10-jdk8.jar: 0.7.10] в co.paralleluniverse.fibers.Fiber.exec(Fiber.java:788) ~ [quasar-core-0.7.10-jdk8.jar: 0.7.10] в co.paralleluniverse.fibers.RunnableFiberTask.doExec (RunnableFiberTask.java:100) ~ [quasar-core-0.7.10-jdk8.jar: 0.7.10] в co.paralleluniverse.fibers.RunnableFiberTask.run (RunnableFiberTask.java:91) ~ [quasar-core-0.7.10-jdk8.jar: 0.7.10] в java.util.concurrent.Executors $ RunnableAdapter.call (Executors.java:511) ~ [?: 1.8.0_191] at java.util.concurrent.FutureTask.run (FutureTask.java:266)~ [?: 1.8.0_191] в java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.access $ 201 (ScheduledThreadPoolExecutor.java:180) ~ [?: 1.8.0_191] в java.util.concurrent.ScheduledThreadPoolFunSecutor.java: 293) ~ [?: 1.8.0_191] в java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) ~ [?: 1.8.0_191] в java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:624) ~ [?: 1.8.0_191] at net.corda.node.utilities.AffinityExecutor $ ServiceAffinityExecutor $ 1 $ thread $ 1.run (AffinityExecutor.kt: 63) ~ [corda-node-4.0.jar:?] Причина: java.util.concurrent.ExecutionException: исключение при сканировании в io.github.classgraph.Scanner.call (Scanner.java:716) ~ [classgraph-4.6.12.jar: 4.6.12] в io.github.classgraph.Scanner.call (Scanner.java:63) ~ [classgraph-4.6.12.jar: 4.6.12] в java.util.concurrent.FutureTask.run (FutureTask.java:266) ~ [?: 1.8.0_191] в java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) ~ [?: 1.8.0_191] в java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) ~ [?: 1.8.0_191] в java.lang.Thread.run (Thread.java:748) [?: 1.8.0_191] Причина: java.lang.OutOfMemoryError: Пространство кучи Java на io.github.classgraph.ClassInfo. (ClassInfo.java:154) ~ [classgraph-4.6.12.jar: 4.6.12] в io.github.classgraph.ClassInfo. (ClassInfo.java:169) ~ [classgraph-4.6.12.jar: 4.6.12] в io.github.classgraph.ClassInfo.addScannedClass (ClassInfo.java:489) ~ [classgraph-4.6.12.jar: 4.6.12] на io.github.classgraph.ClassInfoUnlinked.link (ClassInfoUnlinked.java:168) ~ [classgraph-4.6.12.jar: 4.6.12] на io.github.classgraph.Scanner.call (Scanner.java:649) ~ [classgraph-4.6.12.jar: 4.6.12] на io.github.classgraph.Scanner.call (Scanner.java:63) ~ [classgraph-4.6.12.jar: 4.6.12] в java.util.concurrent.FutureTask.run (FutureTask.java:266) ~ [?: 1.8.0_191] в java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) ~ [?: 1.8.0_191] на java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:624) ~ [?: 1.8.0_191] в java.lang.Thread.run (Thread.java:748) ~ [?: 1.8.0_191]

Ответы [ 2 ]

0 голосов
/ 22 августа 2019

Эта проблема, вероятно, связана с пользовательским кодом сканирования сериализации белого списка.

Нам необходимо увеличить максимальный размер кучи узлов до 1 ГБ.Подробности смотрите по следующей ссылке -
https://r3 -cev.atlassian.net / browse / CORDA-2436

Также см. - https://r3 -cev.atlassian.нетто / просмотр / CORDA-2437? страница = com.atlassian.jira.plugin.system.issuetabpanels% 3Aall-tabpanel

0 голосов
/ 22 августа 2019

Трассировка стека показывает: 

at io.github.classgraph.ClassGraph.scan(ClassGraph.java:1185) ~[classgraph-4.6.12.jar:4.6.12]
at net.corda.core.internal.ClassGraphUtilsKt.pooledScan(ClassGraphUtils.kt:18) ~[corda-core-4.0.jar:?]
at net.corda.core.internal.ClassLoadingUtilsKt.createInstancesOfClassesImplementing(ClassLoadingUtils.kt:22) ~[corda-core-4.0.jar:?]

Другими словами, похоже, что каждый раз, когда вызывается createInstancesOfClassesImplementing, запускается новое сканирование ClassGraph. Если предположить, что этот метод вызывается много раз , то это не только крайне неэффективно, но и сканирование всего пути к классам для каждого нового сканирования может привести к огромным затратам памяти, если ссылка на ScanResultудерживается для каждого нового сканирования.

Трассировка стека также показывает два отдельных сканирования, которые выполняются одновременно, поэтому вы, вероятно, запускаете сканирование из более чем одного потока одновременно.

Правильный способ решить эту проблему - сканировать путь к классам только один раз при инициализации, а затем повторно использовать ScanResult в ClassLoadingUtilsKt вместо повторного сканирования, чтобы каждый раз генерировать новый ScanResult.

...