ISPN-5106 Deadlock on GlobalComponentRegistry when starting a cluster #3416
Conversation
danberindei
force-pushed
the
t_ISPN-5106
branch
from
012ca9d
to
24be731
Compare
danberindei
force-pushed
the
t_ISPN-5106
branch
from
24be731
to
bb4ac75
Compare
| @@ -565,10 +583,11 @@ public void forceAvailabilityMode(String cacheName, AvailabilityMode availabilit | |||
| public void handleViewChange(final ViewChangedEvent e) { | |||
| // Need to recover existing caches asynchronously (in case we just became the coordinator). | |||
| // Cannot use the async notification thread pool, by default it only has 1 thread. | |||
| asyncTransportExecutor.submit(new Runnable() { | |||
| viewHandlingCompletionService.submit(new Callable<Void>() { | |||
There was a problem hiding this comment.
it would be good to have a void submit(Runnable)
There was a problem hiding this comment.
Unfortunately, the way the SemaphoreCompletionService works, it would also need a return value with a Runnable, so it wouldn't make any difference. I'm considering making it an ExecutorService instead though, since I haven't really used the tracking of futures.
There was a problem hiding this comment.
what I have in mind is the submit(Runnable) to invoke the submit(Runnable,T) and ignore the return value.
There was a problem hiding this comment.
Yeah, but then I couldn't declare the variable as CompletionService...
There was a problem hiding this comment.
didn't get it. the CompletionService has a submit(Runnable, T). Also, the field is declared as SemaphoreCompletionService
There was a problem hiding this comment.
I was thinking that having an extra null parameter is no better than return null. Or is there any other reason not to use Callable<Void>?
And yeah, I was thinking about the other submit() call for merge, with uses a local variable that's a CompletionService.
Anyway, I'm replacing the completion service with an executor service, so I'll have a void submit(Runnable) option. Running the tests now...
There was a problem hiding this comment.
I have this rule in my head: I use Callable when a return value is expected, otherwise I use Runnable. And since the original code was a Runnable I would like to keep it :)
danberindei
force-pushed
the
t_ISPN-5106
branch
2 times, most recently
from
4deb0c9
to
8f7de8b
Compare
|
Updated |
danberindei
force-pushed
the
t_ISPN-5106
branch
from
8f7de8b
to
3f0f887
Compare
|
Updated again, including the SemaphoreExecutorService change. |
Move the handling of the initial view to a separate thread.
danberindei
force-pushed
the
t_ISPN-5106
branch
from
3f0f887
to
178f043
Compare
|
testing and pushing... |
|
integrated! thanks @danberindei ! |
https://issues.jboss.org/browse/ISPN-5106
Move the handling of the initial view to a separate thread.