Is there a way to automatically retry Fileupload.upload() opertaion if it fails with IO_Error?
I tried calling upload() again (and it did reach all the way to the web-service)
==> but it did NOT trigger DataEvent.UPLOAD_COMPLETE_DATA when the Retry was completed (i checked with a sniffer that the retry operation did finish successfully)
Thanks for any ideas.
Related
I am working on Spring Kafka implementation and my use case is consume messages from Kafka topic as batch (using batch listener). when I consumer the list of messages, will iterate and call the REST endpoint for message enrichment. In case REST API fails for any runtime exception, I have implemented retry logic using spring retry. I want to stop the container, after the number of retries fails. So planning to use KafkaContainerStoppingErrorHandler to achieve this. Does the KafkaContainerStoppingErrorHandler commits the previous success messages - say if we receive 10 messages, and for message 1,2,3,4, enrichment call is success and for message 5 enrichment API call fails. so when we restart the container, will I get all 10 again or will I receive messages 5- 10?
or is there a way we can achieve above use case? I looked into all types of error handles of Spring kafka and need input on how to achieve above requirement.
You will get them all again.
You can use the DefaultErrorHandler (with a custom recoverer) and throw a BatchListenerFailedException to indicate which record in the batch failed.
The error handler will commit the offsets up to that record and call the recoverer with the failed record; in your custom recoverer you can stop the container (use the same logic as the container stopping error handler).
In versions before 2.8, this same functionality is provided by the RecoveringBatchErrorHandler.
My code performs the following:
1)Create grpc channel
2)start monitoring completion queue in a different thread
3)Issue shutdown on completion queue
After executing step 3, I expect "(cq.Next(&tag, &ok)" to return false as there are no pending events with above 3 steps. But it is observed that "(cq.Next(&tag, &ok)" never returns false. Please let me know if I am missing something.
Thanks,
Ikshu
In order to get channel state notification, a tag was being added to the queue and that use to always post some events. so the cq->next() never returned false. I fixed this issue by achieving same functionality by using already existing standard API for channel state. So closing the bug.
Here is the case, I have an API call using Retrofit that might fail due to a network error. If it fails we will show an error message with a retry button. When the user presses the retry button we need to retry the latest Observable again.
Possible Solutions:
Retry: Retry should be used before subscribing to the observable and it will immediately resubscribe again if an error happens and that is what I don't want, I need to resubscribe only if the user pressed the Retry button.
RetryWhen: It Will keep trying as you emit items until you emit an Observable error then it will stop. Same issue here, I need to not start the retry process unless the user decides to.
Resubscribe to the same Observable: This solution will start emitting the Observable items, the problem with this is that we are using the cache operator, so if one Observable failed, we got the failed item cached and when we do subscribe again, we got the same error again.
Are there any other solutions to go with?
You can go with retryWhen, which parameter - Func1 - returns an Observable which indicates when a retry should happen. For example :
PublishSubject<Object> retryButtonClicked = PublishSubject.create();
Observable
.error(new RuntimeException())
.doOnError(throwable -> System.out.println("error"))
.retryWhen(observable -> observable.zipWith(retryButtonClicked, (o, o2) -> o))
.subscribe();
retryButtonClicked.onNext(new Object());
every time retryButtonClicked emmits an event, Observable will be retried
Here's also an example - https://gist.github.com/benjchristensen/3363d420607f03307dd0
When I run meteor, sometimes I get an error and it hangs on
=> Your application has errors. Waiting for file change.
I think I've let it sit before and it eventually got past that message, but it always takes a long time. What file change is it waiting for? Is it npm or meteor? And is it slow for others, or is it my Koding box being finicky? Can I just stop the process or should I wait?
I don't need help resolving the error that caused this message in this specific instance, just wondering how to handle meteor errors in general when it hangs on this message and curious as to what it means.
I've got a java action that's been suspended for 5 days with this status, and I don't know what oozie wants me to do. Any ideas?
It means that there was an error. And possibly multiple retries if you have retries configured. When retries are configured, after the first error the job goes to START_RETRY and Oozie retries automatically.
After the maximum number of retries is reached, the flow goes to state START_MANUAL. In that state, Oozie assumes that you will intervene and either fix the error and resume the job or kill the job.
There is a little more info in the documentation: http://oozie.apache.org/docs/3.3.2/WorkflowFunctionalSpec.html#a18_User-Retry_for_Workflow_Actions_since_Oozie_3.1