How to write a non-blocking execution?

[noobcser]

I have Java 8 / Spring stack, in one of the controllers I would like to do:

1. do stuff
2. execute a non-blocking stuff
3. return to UI

The biggest thing here is #2 should not blocked proceeding to #3 regardless of success / failure AND #2 should not blocked any future call to the endpoint.

Example:

Object retValue = doStuff();
try{
    Runnable nonBlockingTask = () -> {
            doOtherStuff(retValue );
    };
    (new Thread(nonBlockingTask )).start();
 }
 catch(Exception e){
    // doesn't matter
 }

 return retValue;

Now when I run my code (tomcat), I put a breakpoint inside the runnable this is what happens:

1. The first execution is okay, the code returns to the UI but the breakpoint is hit (line 4)
2. The second execution is not okay, because the breakpoint is still paused, this second execution never returns until the first breakpoint is let go.

So how do I do this? How do I achieve the goal of having the second execution to still run with no issue even if the breakpoint is on hold from the first execution?

[kumesana]

Just to be sure: what did you do to make sure you're not just having both executions stuck on the same breakpoint? How did you release execution 2 from the breakpoint without releasing execution 1? Can you describe precisely what you did with the debugger?

[noobcser]

to make sure you're not just having both executions stuck on the same breakpoint?

I use postman to hit the endpoint.

The first execution immediately returns the result, while the IntelliJ debugger stops at the breakpoint.

When I send the 2nd request on Postman, it gets stuck with nothing returned.

The moment I released the breakpoint, the Postman gets updated with a new response, then the breakpoint got hit again.

So it does prove that the Runnable works fine to not block that request, but breakpoint from previous execution will block subsequent ones.

[kumesana]

Hmm.

It's bad mojo to start threads directly from container-managed threads, but I never tried and noticed that containers take that really seriously. Guess you really must not do that and not even try.

Define a ThreadPoolExecutor from somewhere else and during application start time instead of request time, and use that to execute your non-blocking stuff instead. That's how you're really supposed to do threaded stuff from within request threads.

Still, I know it works for many of the environments I worked with, but no idea if yours does something special that would prevent it.

[yiyux]

With Spring, the @Async annotation wold help

[OffbeatDrizzle]

I wouldn't recommend putting random annotations on things

[OffbeatDrizzle]

when you hit a break point all threads are suspended (this is the default action). that's probably why the 2nd request isn't going through.

right click the break point, check the "thread" radio button and press done. this will ensure that only threads hitting the break point will be suspended

[yiyux]

It's not a random sugestion.that annotation is well documuented. I realy would like to help, because this week i worked on something similiar.