Skip to content

Conversation

@BrennanConroy
Copy link
Member

Fixes #20187

Thanks @jaragones for testing out a fix since I could never repro this.

@BrennanConroy BrennanConroy added the area-signalr Includes: SignalR clients and servers label May 20, 2020
@BrennanConroy BrennanConroy added this to the 5.0.0-preview6 milestone May 20, 2020
@BrennanConroy BrennanConroy requested review from halter73 and wtgodbe May 20, 2020 03:10
closeSubject.doOnError((e) -> {});
closeSubject.onError(new RuntimeException(t));
onClose.invoke(null, t.getMessage());
checkStartFailure();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a chance that checkStartFailure() ever gets called before the Completable is returned from start() meaning we'd need to do the same ting for startSubject?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is technically possible, but very unlikely in practice.

I'm not sure how the global error handler works in that case, because the startSubject will be observed by someone, they just haven't registered the handler by the time onError is called.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's possible, we should handle it.

I'm not sure how the global error handler works in that case, because the startSubject will be observed by someone, they just haven't registered the handler by the time onError is called.

We could test this by intentionally faulting the startSubject before returning. I expect it would also be crashing. How would the runtime even know the startSubject will be observed by someone in the future?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Read the docs for CompletableSubject:

If there were no CompletableObservers subscribed to this CompletableSubject when the onError() was called, the global error handler is not invoked.

This also implies that the "fix" in this PR might not be correct, and the error was happening through some other means. The docs also mention that if onError is called multiple times then it will call the global handler. onError should only ever be called once here, but I'm beginning to think it was somehow triggered multiple times.

halter73
halter73 previously approved these changes May 20, 2020
Copy link
Member

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jaragones!

@jaragones
Copy link

Let's see if it helps :)

@BrennanConroy BrennanConroy dismissed halter73’s stale review June 3, 2020 21:33

Things have changed

closeSubject.onComplete();
try {
closeLock.lock();
closeSubject.onComplete();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check that the closeSubject hasn't already been completed with an error here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling onComplete should noop if the subject is already completed either with an error or without an error.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@halter73 any other feedback?

@BrennanConroy BrennanConroy merged commit 4a66e2d into master Jun 9, 2020
@BrennanConroy BrennanConroy deleted the brecon/javaerror branch June 9, 2020 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-signalr Includes: SignalR clients and servers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Signal R Core Java Client Crashing

4 participants