All
The dubbo 2.7.5 is hard to debug with the vast usage of java 8 的语法糖(like
lambda, System.out::println, Consumer.accept). I don't know where the line
number from the exception stack trace. In this consideration, i am not dare to
upgrade 2.7.5 as users is not able to solve the issue by themselves, while the
questions will rush to our middleware team. Considering of thousands of
applications in our company, we are not able to hold the consultation. So, for
the middleware, is functional programing helpful for the users?
Caused by: java.lang.NoSuchMethodError:
io.netty.util.internal.PlatformDependent.allocateUninitializedArray(I)[B
...
at
org.apache.dubbo.bootstrap.DubboBootstrap$Helper.doExportUrlsFor1Protocol(DubboBootstrap.java:1458)
~[dubbo-2.7.5-20191030.052311-18.jar:2.7.5-SNAPSHOT]
at
org.apache.dubbo.bootstrap.DubboBootstrap$Helper.doExportUrls(DubboBootstrap.java:1297)
~[dubbo-2.7.5-20191030.052311-18.jar:2.7.5-SNAPSHOT]
at
org.apache.dubbo.bootstrap.DubboBootstrap$Helper.doExport(DubboBootstrap.java:1269)
~[dubbo-2.7.5-20191030.052311-18.jar:2.7.5-SNAPSHOT]
at
org.apache.dubbo.bootstrap.DubboBootstrap$Helper.lambda$export$0(DubboBootstrap.java:1181)
~[dubbo-2.7.5-20191030.052311-18.jar:2.7.5-SNAPSHOT]
at
org.apache.dubbo.common.threadpool.concurrent.ScheduledCompletableFuture.lambda$schedule$0(ScheduledCompletableFuture.java:37)
~[dubbo-2.7.5-20191030.052311-18.jar:2.7.5-SNAPSHOT]
at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
~[?:1.8.0_221]
at java.util.concurrent.FutureTask.run(FutureTask.java) ~[?:1.8.0_221]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
~[?:1.8.0_221]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
~[?:1.8.0_221]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_221]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_221]
at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_221]
Secondly, the change of the async start makes the startup faster, but the stack
trace was broken when exception occurred. For the request chain, the
performance means a lot, but is performance important for the startup chain? I
think, we are able to pave a new way for async startup to faster the speed if
needed, do not broken on the current situation.
Best Regards
Haiyang
