These are chat archives for ReactiveX/RxJava

3rd
Feb 2016
Lech Głowiak
@LGLO
Feb 03 2016 10:38
Hello All!
I come with question. I have Subscription that reads sth from some resource. That resource becomes unavailable but there is a hope it's just temporarily (that is RabbitMQ auto-recoverable channel). Should subscription.onError be called immediately or maybe after some timeout? Or maybe behaviour should depend on signalled demand?
Javier Domingo Cansino
@txomon
Feb 03 2016 11:02
@LGLO I would do it calling an onError, put in the pipeline a retry, for example to retry twice and then fail. Take into account that onError is meant to be used for fatal errors, stuff you can handle should be used through standard onNext
(my advice)
Lech Głowiak
@LGLO
Feb 03 2016 11:08
I'm not sure if I follow you.
that is for an error that should be retried always
Lech Głowiak
@LGLO
Feb 03 2016 11:11
Ok, thank you!
Dorus
@Dorus
Feb 03 2016 11:26
Also be careful to put the retry close to the source, some operators (like observeOn) delete queued message when they get an onError.
Javier Domingo Cansino
@txomon
Feb 03 2016 11:27
that is why I said that onError is just for fatal errors
understanding fatal as closing the app
Dorus
@Dorus
Feb 03 2016 11:31
Nah, fatal errors you can throw from your functions like subscribe. These should bring down your app as per Rx guidelines.
onError on the other hand is nothing more than a function that throws an exception.
IMHO it's a bit of a bug that RxJava assumes onError to be more fatal than that.
Also last time i made a bug report for that i was told it would be configurable in the next version.
#3542
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:17
Is there a good way to detach a background task in rx? Here’s what I mean, I’d like to make some background call and do somthing with the result (e.g. subscribe) but I really don’t want to tie it to a particular activity (e.g. using rxlifecycle). Is it possible to call a subscription that just automatically expires? Say after a timeout for a example. I know I won’t get more than 1 element in that subscription btw.
Dorus
@Dorus
Feb 03 2016 16:17
take(1)?
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:17
i still need to subscribe to that right?
and manage the subscription to prevent leaks
Dorus
@Dorus
Feb 03 2016 16:18
and takeUntil()
both unsubscribe after a while
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:19
oh
that’s awesome!
Dorus
@Dorus
Feb 03 2016 16:19
Or you just make sure your source yields an onError or onCompleted
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:19
my source does
or at least should
Dorus
@Dorus
Feb 03 2016 16:19
take(1) will unsubscribe after 1 element, but could stay connected forever if there are no elements. takeUntil can end after a timeout if you combine it with an Observable.Timer etc.
there is also timeout that gives an error if it takes too long. Also usefull
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:20
i think my source already has its own timeout mechanism
Dorus
@Dorus
Feb 03 2016 16:20
Oh, then you need nothing
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:20
but it’s still suboptiomal that i’m keeping a reference to an activity
Dorus
@Dorus
Feb 03 2016 16:20
After a onCompleted all Rx resources should be cleaned up.
no need to call unsubscribe yourself.
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:21
won’t that be pathological in some cases?
Dorus
@Dorus
Feb 03 2016 16:21
You only keep the reference if you want to end your activity early
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:21
my timeout is aleady 5 seconds
and that means i will keep an extra ref. to the activity for upto 5 seconds in some cases
even though it’s unnecessary
Dorus
@Dorus
Feb 03 2016 16:21
I think it's perfectly safe to lose the reference.
Just not recommended
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:22
you mean lose the reference to the activity?
I’m not sure how to do that
Dorus
@Dorus
Feb 03 2016 16:22
well if you do not store the subscription you get from Subscribe, you have that right?
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:23
yeah
Dorus
@Dorus
Feb 03 2016 16:23
But the subscription will stay connected for at least those 5 seconds.
Rudi Grinberg
@rgrinberg
Feb 03 2016 16:23
at most you mean
but yeah
Dorus
@Dorus
Feb 03 2016 16:23
But as long as the source is guranteed to finish, it should be fine.