Block terminated with an error - Исправление ошибок и поиск оптимальных решений проблем

Содержание

#block terminated with an error with Eureka and Micronaut 3.0.0-SNAPSHOT #5882
Comments
Steps to Reproduce
Expected Behaviour
Actual Behaviour
Environment Information
Spring Blog
Flight of the Flux 2 — Debugging Caveats
Debugging in a Reactive World
Demonstrating the issue with vanilla async code
Demonstrating the issue in Reactor
Making Things Better
Back to classics: log
Enriching stacktraces with Debug Mode
Bringing the cost down with checkpoint
Conclusion
Unable to start Netty (TimeoutException) #9905
Comments
AssemblySnapshotException without details #1001
Comments

#block terminated with an error with Eureka and Micronaut 3.0.0-SNAPSHOT #5882

The GraalVM test application for discovery-client Eureka fails in JIT mode (and also as native image).

The error doesn’t happens all the time and I’ve only been able to reproduce it using JDK 11. Sometimes I start the application, send the curl request and it fails. Other times I start the application, wait a few seconds and then send the curl request.

Another thing I do to reproduce the error is deleting all local 3.0.0-SNAPSHOT artifacts (for both core and discovery-client) and then run the application.

Steps to Reproduce

git clone https://github.com/micronaut-graal-tests/micronaut-service-discovery-eureka
cd micronaut-service-discovery-eureka
git checkout error-micronaut3
docker run -it —rm -p 8761:8761 registry.gitlab.com/micronaut-projects/micronaut-graal-tests/eureka-server
Use Java 11
./gradlew run
curl localhost:8080/api/hello/Micronaut

Expected Behaviour

The application should return Hello Micronaut

Actual Behaviour

Environment Information

Operating System: Linux Mint 20.1
Micronaut Version: 3.0.0-SNAPSHOT
JDK Version: 11

The text was updated successfully, but these errors were encountered:

Источник

Spring Blog

Flight of the Flux 2 — Debugging Caveats

This blog post is the second in a series of posts that aim at providing a deeper look into Reactor’s more advanced concepts and inner workings.

It is derived from my Flight of the Flux talk, which content I found to be more adapted to a blog post format.

I’ll update the table below with links when the other posts are published, but here is the planned content:

Assembly vs Subscription
Debugging caveats (this post)
Hopping Threads and Schedulers
Inner workings: work stealing
Inner workings: operator fusion

If you’re missing an introduction to Reactive Streams and the basic concepts of Reactor, head out to the site’s learning section and the reference guide.

Without further ado, let’s jump in:

Debugging in a Reactive World

Switching from an imperative, blocking paradigm to a reactive, non-blocking one brings benefits but also comes with some caveats. One of these is the debugging experience. Why is that?

Primarily because you’ve learned to rely on the good old stacktrace, but suddenly this invaluable tool becomes far less valuable due to the asynchronous aspect of reactive programming. This is not specific to reactive programming though: as soon as you introduce asynchronous code, you create a boundary in the program between the code that schedules and the code that asynchronously executes.

Demonstrating the issue with vanilla async code

Let’s take an example with an ExecutorService and a Future (no Reactor code here):

This example is a bit contrived, but let’s imagine that we have these two out of three path in the code that can lead to the asynchronous task throwing an IndexOutOfBoundsException … How helpful would the stacktrace be?

the Future ’s get() method threw an ExecutionException
the cause is an IndexOutOfBoundsException
the code throwing is in the submit(() -> source.get(5)) lambda line 76
it executed in a FutureTask , from something called a ThreadPoolExecutor , itself running in a Thread …
we have two potential sources that could cause this but no idea which one is the culprit (which path was taken in the test prior to calling submit() ).

Not terribly useful 🙁

Demonstrating the issue in Reactor

If we look for a Reactor equivalent to the above code, we can come up with this:

Which triggers the following stacktrace:

We see the ArrayIndexOutOfBoundsException again, hinting at a source that was too short for the MonoElementAt operator
We see that it came from an onComplete , itself triggered by request … and a bunch of other steps in reactor.core.publisher
With a bit of familiarity with these reactor methods, we might deduce that the pipeline was made up of range ( FluxRange.subscribe ), elementAt and subscribeOn …
It seems the throwing code was executed from the worker Thread of a ThreadPoolExecutor
The trail goes cold here…

Worse, even if we did get rid of subscribeOn we’d still wouldn’t discover which of the two possible error paths was triggered:

Gives the stacktrace:

That is because, as we saw previously, there is an additional “boundary” in code between assembly and subscription. The trail only goes back to the point of subscription (here the block() ) 🙁

So using stacktraces for analysis and debugging purposes is harder in an asynchronous world, and even a bit harder in Reactor (because it is asynchronous and has a lazy-by-default approach with assembly vs subscription). But fortunately there are tools in the library to try and alleviate that fact.

Making Things Better

Back to classics: log

Remember when you sprinkled your imperative code with print statements? It might not be as cool as firing up the step debugger, but sometimes it is the quick and dirty solution you need.

In Reactor, you have the log() operator:

It logs Reactive Stream signals: onNext , onComplete , onError (and even onSubscribe , cancel and request !)
You can tune it to whitelist only part of these signals
You can choose a particular Logger as well

In short, log is the quick and dirty solution to get an easy bird eye’s view of what is going on at one step of your sequence. Use it liberally during development, with the possibility of specifying a “name” to each log call to differentiate them.

Using log(String) can be diverted to get a hint at which source causes the error:

The stacktrace itself isn’t much more interesting (apart from mentioning the MonoLogFuseable class, but the log itself contains this interesting tidbit:

At least we get our hardcoded source C label…

Enriching stacktraces with Debug Mode

Another approach that is available in Reactor is to try and get back the assembly information in the runtime stacktraces.

This can be done by activating the so-called “debug mode” via the Hooks class:

What does it do? It makes each operator instantiation (aka assembly) capture a stacktrace and keep it for later.

If an onError reaches one operator, it will attach that assembly stacktrace to the onError ’s Throwable (as a suppressed Exception ). As a result, when you see the stacktrace you’ll get a more complete picture of both the runtime AND the assembly.

With debug mode on, in our earlier example we would be able to see which assembly path was taken and which source was actually processed:

Which produces the following stacktrace:

Notice the last line? Yay 😀

Bringing the cost down with checkpoint

One drawback of using Hooks.onOperatorDebug() is that it does the assembly stacktrace capture for every single operator used in the application. Filling a single stacktrace is a costly operation, so it goes without saying that this can have an heavy impact on performance. As a result, this is only recommended in a development setting.

Fortunately, you can bring the cost down a little if you identify parts of your codebase that are prone to that sort of source ambiguity.

By using the checkpoint() operator, it is possible to activate the assembly trace capture only at that specific point in the codebase. You can even do entirely without the filling of a stacktrace if you give the checkpoint a unique and meaningful name using checkpoint(String) :

This produces the following stacktrace:

Notice the is identified by light checkpoint [source just(1,2,3,4)]. , which gives us our culprit (because we used a meaningful description for the checkpoint).

Conclusion

In this article, we’ve learned that stacktraces can be less useful in asynchronous programming. This effect is further compounded by the lazy way Reactor let you build reactive sequences.

We’ve looked at the worst cases that can be encountered and at several ways this problem can be lessened.

The whole code can be found in a gist here.

In the next instalment, we’ll learn about schedulers and how to hop from one thread to another.

Источник

Unable to start Netty (TimeoutException) #9905

Issue: Netty is unable to start due to timeout in the latest ‘2.0.0.M3’. In ‘2.0.0.M2’ everything works fine.

[reactor-core-3.1.0.M3.jar:3.1.0.M3] at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:87)

[reactor-core-3.1.0.M3.jar:3.1.0.M3] at reactor.core.publisher.Mono.block(Mono.java:1280)

[reactor-core-3.1.0.M3.jar:3.1.0.M3] at reactor.ipc.netty.tcp.BlockingNettyContext. (BlockingNettyContext.java:55)

[reactor-netty-0.7.0.M1.jar:0.7.0.M1] at reactor.ipc.netty.tcp.BlockingNettyContext. (BlockingNettyContext.java:45)

[reactor-netty-0.7.0.M1.jar:0.7.0.M1] at reactor.ipc.netty.NettyConnector.start(NettyConnector.java:53)

[reactor-netty-0.7.0.M1.jar:0.7.0.M1] at org.springframework.boot.web.embedded.netty.NettyWebServer.start(NettyWebServer.java:64)

[spring-boot-2.0.0.M3.jar:2.0.0.M3] . 10 common frames omitted Suppressed: java.lang.Exception: #block terminated with an error at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:88)

[reactor-core-3.1.0.M3.jar:3.1.0.M3] . 15 common frames omitted Caused by: java.util.concurrent.TimeoutException: HttpServer couldn’t be started within 3000ms at reactor.ipc.netty.tcp.BlockingNettyContext. (BlockingNettyContext.java:53)

[reactor-netty-0.7.0.M1.jar:0.7.0.M1] . 13 common frames omitted»>

Environment
Kotlin: 1.1.3-2
SpringBoot: 2.0.0.M3
Java: 1.8.0_112 (build 1.8.0_112-b16)

Steps to reproduce
Create a project from Spring Initializr using Spring Boot: 2.0.0 M3 with Reactive Web

The text was updated successfully, but these errors were encountered:

It is not related to https://thoeni.io/post/macos-sierra-java, as my /ect/hosts have the required entries for 127.0.0.0 and ::1 .

Has M2 worked successfully since you experienced this problem with M3?

Yes, I am using M2 currently and it is running successfully.

@ganesshkumar I can’t recreate this so it’s either specific to your environment or there’s more to it than you’ve described. To eliminate the latter, can you please provide a minimal sample that reproduces the problem?

Here is the repo I just created using Spring Initializr.

I have added the complete stack track in README. Let me know if you want more details.

Thanks for the sample. It starts fine for me via both bootRun and java -jar so it would appear that the problem is in some way specific to your environment.

Can you please try running with logging.level.root=debug so that we can see what’s going on during startup? A thread dump taken towards the end of the 5 second period while it waits for Netty to start may also be informative.

I have the same issue too. In both my Macbook pro and dell xps 13(arch linux).

This is log with logging.level.root=debug :
artemis.log.zip

@wilkinsona I have updated the logs in the repo.

Log via gradle task by running ./gradlew bootRun —debug

Log via application.properties by adding logging.level.root=debug in application.properties

Thank you, @ganesshkumar. In both cases there’s a

5 second gap between these two lines:

On my machine that gap is less than 30ms:

Interestingly, a call to InetAddress.getLocalHost() is made between those two lines being logged. The stack trace is:

I know you said above that you do not believe that it’s related to InetAddress.getLocalHost() , but I suspect that it may well be. How long does a call to InetAddress.getLocalHost() take on your machine? If it’s quick and my suspicion is wrong, I think we’ll need a thread dump during the 5 second window after the first line has been logged to make further progress.

I follow this solution then it work now.

@hendisantika We don’t know exactly what the problem is just yet. We still need some more information, specifically:

How long does a call to InetAddress.getLocalHost() take on your machine? If it’s quick and my suspicion is wrong, I think we’ll need a thread dump during the 5 second window after the first line has been logged to make further progress.

Sorry for delayed update.

After updating to macOS Sierra 10.12.6, everything is working fine as expected.

@hendisantika, just double check you have the hostname as third field in /etc/hosts file.

I have faced this issue around M2. I had both the entries but the missing hostname field made InetAddress.getLocalHost() to take more than 3s.

My mac already used macOS Sierra 10.12.6 and I already followed the /etc/host too @ganesshkumar. But, I still got the issue.

Should I post the repo so that anyone can test it?

I am facing the same issue for 2.0.0.M3 while it works fine for 2.0.0.M2

we are still waiting for a sample. Can you please share one?

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-issuemaster and the others member like @mohitsinha or @ganesshkumar can try my repo to see if it works on your machine.

BTW, I already follow the /etc/host but it still got error.

Источник

AssemblySnapshotException without details #1001

We try to retrieve app and service usage events of some larger CF installations and receive the following exceptions:

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at reactor.core.publisher.Mono.checkpoint(Mono.java:1730)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at reactor.core.publisher.Mono.checkpoint(Mono.java:1680)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at org.cloudfoundry.reactor.tokenprovider.AbstractUaaTokenProvider.token(AbstractUaaTokenProvider.java:272)

[cloudfoundry-client-reactor-3.15.0.RELEASE.jar!/:na] at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)

[na:1.8.0_212] at org.cloudfoundry.reactor.tokenprovider.AbstractUaaTokenProvider.getToken(AbstractUaaTokenProvider.java:108)

[cloudfoundry-client-reactor-3.15.0.RELEASE.jar!/:na] at org.cloudfoundry.reactor.util.AbstractReactorOperations.addAuthorization(AbstractReactorOperations.java:258)

[cloudfoundry-client-reactor-3.15.0.RELEASE.jar!/:na] at reactor.core.publisher.Mono.transform(Mono.java:4093)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at org.cloudfoundry.reactor.util.AbstractReactorOperations.lambda$null$4(AbstractReactorOperations.java:103)

[cloudfoundry-client-reactor-3.15.0.RELEASE.jar!/:na] at reactor.ipc.netty.http.client.HttpClient.lambda$handler$4(HttpClient.java:429)

[reactor-netty-0.7.9.RELEASE.jar!/:0.7.9.RELEASE] at reactor.ipc.netty.http.client.MonoHttpClientResponse$HttpClientHandler.apply(MonoHttpClientResponse.java:121)

[reactor-netty-0.7.9.RELEASE.jar!/:0.7.9.RELEASE] at reactor.ipc.netty.http.client.MonoHttpClientResponse$HttpClientHandler.apply(MonoHttpClientResponse.java:84)

[reactor-netty-0.7.9.RELEASE.jar!/:0.7.9.RELEASE] at reactor.ipc.netty.channel.ChannelOperations.applyHandler(ChannelOperations.java:380)

[reactor-netty-0.7.9.RELEASE.jar!/:0.7.9.RELEASE] at reactor.ipc.netty.http.client.HttpClientOperations.onHandlerStart(HttpClientOperations.java:505)

[reactor-netty-0.7.9.RELEASE.jar!/:0.7.9.RELEASE] at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)

[netty-common-4.1.29.Final.jar!/:4.1.29.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)

[netty-common-4.1.29.Final.jar!/:4.1.29.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:446)

[netty-transport-4.1.29.Final.jar!/:4.1.29.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)

[netty-common-4.1.29.Final.jar!/:4.1.29.Final] at java.lang.Thread.run(Thread.java:748)

[na:1.8.0_212] Suppressed: reactor.core.publisher.FluxOnAssembly$AssemblySnapshotException: null at reactor.core.publisher.MonoOnAssembly. (MonoOnAssembly.java:62)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at reactor.core.publisher.Mono.checkpoint(Mono.java:1730)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at reactor.core.publisher.Mono.checkpoint(Mono.java:1680)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at org.cloudfoundry.reactor.client.v2.serviceusageevents.ReactorServiceUsageEvents.list(ReactorServiceUsageEvents.java:55)

[cloudfoundry-client-reactor-3.15.0.RELEASE.jar!/:na] at Suppressed: java.lang.Exception: #block terminated with an error at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:93)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] at reactor.core.publisher.Mono.block(Mono.java:1493)

[reactor-core-3.2.3.RELEASE.jar!/:3.2.3.RELEASE] . Suppressed: reactor.core.publisher.FluxOnAssembly$AssemblySnapshotException: null at reactor.core.publisher.MonoOnAssembly. (MonoOnAssembly.java:62)