Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 13 13:14
    Tembrel commented #221
  • Jan 13 13:04
    Tembrel commented #221
  • Jan 13 08:10
    whiskeysierra commented #221
  • Jan 12 18:51
    Tembrel commented #221
  • Jan 08 18:01
    paulius-p commented #221
  • Jan 08 16:08
    jhalterman commented #221
  • Jan 08 16:07
    jhalterman commented #221
  • Jan 08 16:06
    jhalterman commented #221
  • Jan 08 16:01
    whiskeysierra commented #221
  • Jan 08 15:56
    jhalterman labeled #221
  • Jan 08 15:55
    paulius-p opened #221
  • Jan 07 09:48
    RuslanSafa closed #217
  • Jan 04 14:31
    coveralls commented #220
  • Jan 04 14:29
    PascalSchumacher opened #220
  • Dec 30 2019 09:54
    RuslanSafa commented #217
  • Dec 25 2019 20:23
    jhalterman commented #217
  • Dec 25 2019 20:22
    jhalterman commented #217
  • Dec 24 2019 06:35
    RuslanSafa commented #217
  • Dec 24 2019 06:33
    RuslanSafa commented #217
  • Dec 23 2019 02:12
    jhalterman labeled #215
Jonathan Halterman
@jhalterman
couldn't you put whatever code you want inside the handleIf method?
breaker.handleIf(t -> {
  if (t instanceof MyException) {
   doSomeThings();
   return true;
  }
  return false;
});
Daniil Gaidukov
@danzik
sure, I can, but I thought maybe failsafe has a separate method for that or listener.
@jhalterman anyway thx for the response!
Jonathan Halterman
@jhalterman
Well those handle methods are meant to return pretty quickly and not do much other work. But you could use it in this way if you like.
Jonathan Halterman
@jhalterman
Released Failsafe 2.3.0, with a fix for Timeout interrupts and a change that no longer wraps synchronous Errors in FailsafeException. https://github.com/jhalterman/failsafe/blob/master/CHANGES.md
Jonathan Halterman
@jhalterman
There's a new Failsafe website: http://jodah.net/failsafe/
Hopefully this makes reading the docs a bit easier. Feedback welcome.
Maxim Kolesnikov
@xCASx
@jhalterman good job!
Willi Schönborn
@whiskeysierra
Very nice indeed
Jonathan Halterman
@jhalterman
Thanks :thumbsup:
Jonathan Halterman
@jhalterman
Actually having a proper website is allowing me to fill in a bit more info where before I didn't want the README to get too long.
Jonathan Halterman
@jhalterman
Released 2.3.1 with a few minor fixes/improvements https://github.com/jhalterman/failsafe/blob/master/CHANGES.md#231
Ilja S
@iljasss_twitter
Hello, very useful lib. One question, is that possible to throw an original exception on failure (or when retries exceeded) instead of FailsafeException?
Jonathan Halterman
@jhalterman
@iljasss_twitter Yes - FailsafeException is only thrown if the original exception is a checked Exception. This is necessary because the API does not declare throws Exception, so it wraps the original exception in FailsafeException when necessary. If the original exception is a RuntimeException it will not be wrapped and will be thrown directly.
Ilja S
@iljasss_twitter
Oh, ok thank you!
Joe Stazak
@joestazak
Hello! I am upgrading an application from version 1 -> 2 and have run into an issue I was hoping someone could help me with. There are a handful of places that was using the v1 .withFallback() function which had the Throwable available in the context, in v2 I am migrating these to the Fallback policy and it does not appear to have the Throwable in the context. Is there any way to get this information? Based off of the error messaging we need to have different Fallback objects created.
Jonathan Halterman
@jhalterman
@joestazak Yea the Fallback API is a bit different now in that it's based on events, so the Fallback you create consumes an ExecutionAttemptedEvent: http://jodah.net/failsafe/javadoc/net/jodah/failsafe/Fallback.html#of-net.jodah.failsafe.function.CheckedConsumer-
Ex: Fallback.of(e -> log.error("Falling back on exception", e.getLastFailure());
Alternatively, if you want your Fallback to convert one exception to another, you can use ofException: http://jodah.net/failsafe/javadoc/net/jodah/failsafe/Fallback.html#ofException-net.jodah.failsafe.function.CheckedFunction-
Joe Stazak
@joestazak
Thanks for the information! That looks like what I need. The v2 is much easier to program against by the way, so kudos to anyone here who worked on it.
Jonathan Halterman
@jhalterman
Great. Glad you like it. Please spread the word :)
the-mod
@the-mod
Hi, I am using Failsafe 2.3.1. for breaking a circuit. I observed that the state isn't automatically moving from open to half-open after the given duration of delay. Only if I call the wrapped method it changes. Is it possible to move without any call to next states?
Willi Schönborn
@whiskeysierra
Can you share your configuration?
the-mod
@the-mod
private CircuitBreaker<CompletableFuture<Void>> circuitBreaker = new CircuitBreaker<CompletableFuture<Void>>()
          .withDelay(Duration.ofSeconds(60))
          .withFailureThreshold(1, 4)
          .handleResultIf(s -> s.isCompletedExceptionally())
          .onClose(() -> {
            System.out.println("close");
          })
          .onOpen(() -> {
            System.out.println("open");
          });



circuitBreaker.onHalfOpen(() -> {
      System.out.println("Skipping Circuit Breaker HalfOpen State, forward to Close State");
      circuitBreaker.close();
});
Willi Schönborn
@whiskeysierra
It won't change it's state just based on time. An attempted execution 60+ seconds after it went from closed to open should move it to half open.
the-mod
@the-mod
ja that is what I observed. is it possible to move to half open without doing any request?
Manually recordSuccess maybe?
Willi Schönborn
@whiskeysierra
What problem are you trying to solve?
the-mod
@the-mod
Basically I am processing and forward events from a log and want to stop reading if receiver isn't reachable
But I want to try start processing again after a timespan without keeping events in memory to send again to move states of circuit breaker
Willi Schönborn
@whiskeysierra
Does your queue/log support checkpoints or re-reads?
Keep the latest events in memory and just trying to re-send doesn't sound that bad to me
the-mod
@the-mod
Ja it supports checkpoints... I have to think about the concept. But thanks anyways :)
Jonathan Halterman
@jhalterman
Yea you'll need to recordResult/recordSuccess/recordFailure and the CircuitBreaker may transition. It's the execution result that causes a breaker to transition from closed->open, not time. We could transition from open->half-open or half-open->closed based solely on time, but then we'd need a separate Timer thread to do this which I'm hesitant to do. So currently CircuitBreaker only transitions when an execution result is recorded.
Willi Schönborn
@whiskeysierra
@jhalterman Technically you could use the default scheduler that is used for retries and timeouts, couldn't you?
Jonathan Halterman
@jhalterman
Ah yes, I was thinking of the pre-Java-8 Failsafe when we didn't have the common pool. Yea, we could use that.
Pablo Rodriguez
@PabloMR92

Hi guys! Quick question, consider having a composition as this example:
Failsafe.with(fallback, circuitBreaker).get(supplier);
Where fallback has a logger on the onSuccess method:
fallback.onSuccess(e -> log.info("Connected to backup"));

I've noticed that even if the policy is never executed, it always goes into the onSuccess method. Is this the desired behaviour?

Jonathan Halterman
@jhalterman
@PabloMR92 What do you mean the policy is never executed - can you give an example?
Pablo Rodriguez
@PabloMR92
public static boolean exampleFunction() {
    System.out.println("No error in here, log should be expected!");

    return true;
}
public static void main(String args[]){
    Fallback<Boolean> fallback = Fallback.of(Boolean.FALSE)
            .onFailure(e -> System.out.println("Oh no, error on Fallback"))
            .onSuccess(e -> System.out.println("Wait why is this one called if neither CircuitBreaker or supplier errored???"));

    CircuitBreaker<Boolean> circuitBreaker = new CircuitBreaker<Boolean>()
            .handle(Exception.class)
            .withFailureThreshold(5)
            .withSuccessThreshold(3)
            .onFailure(e -> System.out.println("Oh no, error on CircuitBreaker"))
            .withDelay(Duration.ofMinutes(1));

    Boolean aBoolean = Failsafe.with(fallback, circuitBreaker).get(() -> exampleFunction());

    System.out.println(aBoolean);
}
yields this output:
No error in here, log should be expected! Wait why is this one called if neither CircuitBreaker or supplier errored??? true
I would expect that the onSuccess/onFailure on a Policy level to be called only when that particular Policy on the chain was evaluated
Luca Pertile
@fante76
Hello everybody. I'm still using FailSafe 1.x; what are new features in 2.x ?
...and where can I find old version documentation?
Willi Schönborn
@whiskeysierra
@fante76 https://github.com/jhalterman/failsafe/tree/1.x. 2.0 (https://jodah.net/failsafe/) generally speaking has now support for arbitrary policies, not just retries/circuit breakers.
Luca Pertile
@fante76
@whiskeysierra Thank you very mutch!
the-mod
@the-mod

Hi,

I implemented a RetryPolicy which should retry completableFutures.
I realizied, that the handleResultIf is not working, due to when it is called the future isn't done.
How can I wait for the future to be done and then decide to retry or not?
client.connect() is returning a CompletableFuture<Void>

RetryPolicy<CompletableFuture<Void>> retryPolicy = new RetryPolicy<CompletableFuture<Void>>().handleResultIf(s -> s.isCompletedExceptionally()).withDelay(Duration.ofSeconds(delay)).withMaxRetries(attempts);

Failsafe.with(retryPolicy).with(threadPool).get(() -> client.connect());
Willi Schönborn
@whiskeysierra
.get(..) is for synchronous retries. You need getStageAsync, iirc and your policy should be Policy<Void> then and then you don't need any .handle* call
Willi Schönborn
@whiskeysierra
If you want the blocking retry you need to block on the future (join()) within your get(..) statement
the-mod
@the-mod
@whiskeysierra got it thx :)