Safegard status

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Safegard status

Bruno Baptista
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Raymond Auge
Romain, you may not have seen this, but the OSGi Alliance worked on a (self-implemented) library (yes a non-OSGi library :) ) that might prove useful. It is very tiny so perhaps it could simply be embedded into the geronimo safeguard implementation.

Promises
=======
maven dep [1]
spec [2]

Considering the details of the fault tolerance specification (which honestly I have only read the readme ;) )
  • TimeOut: Define a duration for timeout
    Promises supports timeouts natively

  • RetryPolicy: Define a criteria on when to retry
    I think this is pretty easy to implement on Promises using a timeout + a fallback

  • Fallback: provide an alternative solution for a failed execution.
    Promises supports fallbacks natively

  • Bulkhead: isolate failures in part of the system while the rest part of the system can still function.
    If this is referring to executing tasks without blocking + callbacks + failure states, and such, then this is a native ability of Promises.

  • CircuitBreaker: offer a way of fail fast by automatically failing execution to prevent the system overloading and indefinite wait or timeout by the clients.
    Plenty of features to combine for this.

Just a thought!
- Ray




On Thu, Aug 30, 2018 at 6:00 AM, Romain Manni-Bucau <[hidden email]> wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
Well, overall idea is to not conflict at all and stay light (stack generally are not worth it for these specs from my experience) so I still think the original plan is ok and technically it is easy and enables us to make our ecosystem (asf with tomee, owb etc) consistent.

That said we can be pluggable ;)

Le jeu. 30 août 2018 19:14, Raymond Auge <[hidden email]> a écrit :
Romain, you may not have seen this, but the OSGi Alliance worked on a (self-implemented) library (yes a non-OSGi library :) ) that might prove useful. It is very tiny so perhaps it could simply be embedded into the geronimo safeguard implementation.

Promises
=======
maven dep [1]
spec [2]

Considering the details of the fault tolerance specification (which honestly I have only read the readme ;) )
  • TimeOut: Define a duration for timeout
    Promises supports timeouts natively

  • RetryPolicy: Define a criteria on when to retry
    I think this is pretty easy to implement on Promises using a timeout + a fallback

  • Fallback: provide an alternative solution for a failed execution.
    Promises supports fallbacks natively

  • Bulkhead: isolate failures in part of the system while the rest part of the system can still function.
    If this is referring to executing tasks without blocking + callbacks + failure states, and such, then this is a native ability of Promises.

  • CircuitBreaker: offer a way of fail fast by automatically failing execution to prevent the system overloading and indefinite wait or timeout by the clients.
    Plenty of features to combine for this.

Just a thought!
- Ray




On Thu, Aug 30, 2018 at 6:00 AM, Romain Manni-Bucau <[hidden email]> wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Raymond Auge


On Thu, Aug 30, 2018 at 1:33 PM, Romain Manni-Bucau <[hidden email]> wrote:
Well, overall idea is to not conflict at all and stay light (stack generally are not worth it for these specs from my experience)

Oh, it's self implemented. i.e. you don't have N implementation. You simply use the utility library and doesn't need an OSGi framework at all. You can use it in plain Java.

- Ray
 
so I still think the original plan is ok and technically it is easy and enables us to make our ecosystem (asf with tomee, owb etc) consistent.

That said we can be pluggable ;)

Le jeu. 30 août 2018 19:14, Raymond Auge <[hidden email]> a écrit :
Romain, you may not have seen this, but the OSGi Alliance worked on a (self-implemented) library (yes a non-OSGi library :) ) that might prove useful. It is very tiny so perhaps it could simply be embedded into the geronimo safeguard implementation.

Promises
=======
maven dep [1]
spec [2]

Considering the details of the fault tolerance specification (which honestly I have only read the readme ;) )
  • TimeOut: Define a duration for timeout
    Promises supports timeouts natively

  • RetryPolicy: Define a criteria on when to retry
    I think this is pretty easy to implement on Promises using a timeout + a fallback

  • Fallback: provide an alternative solution for a failed execution.
    Promises supports fallbacks natively

  • Bulkhead: isolate failures in part of the system while the rest part of the system can still function.
    If this is referring to executing tasks without blocking + callbacks + failure states, and such, then this is a native ability of Promises.

  • CircuitBreaker: offer a way of fail fast by automatically failing execution to prevent the system overloading and indefinite wait or timeout by the clients.
    Plenty of features to combine for this.

Just a thought!
- Ray




On Thu, Aug 30, 2018 at 6:00 AM, Romain Manni-Bucau <[hidden email]> wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
failsafe as well but as a library (us/geronimo) we don't have guarantee it is stable and controlled and we had some "surprises". Question can be phrased as such "does the time to discuss if we can implement it is sufficient to implement it?", IMHO it is so we can just do it for one of the coming release.

I'll give you a simple example: commons-lang3 has some of these parts, but it is getting cut in N libraries which will grow independently which is the promise of N (N > 1) conflicts for us.
So since the cost to have it here is very low it does worth it IMHO and we own a full apache stack which is very valuable for the foundation IMHO.
Now if the OSGi impl wants to donate it to ASF we can merge both.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 19:42, Raymond Auge <[hidden email]> a écrit :


On Thu, Aug 30, 2018 at 1:33 PM, Romain Manni-Bucau <[hidden email]> wrote:
Well, overall idea is to not conflict at all and stay light (stack generally are not worth it for these specs from my experience)

Oh, it's self implemented. i.e. you don't have N implementation. You simply use the utility library and doesn't need an OSGi framework at all. You can use it in plain Java.

- Ray
 
so I still think the original plan is ok and technically it is easy and enables us to make our ecosystem (asf with tomee, owb etc) consistent.

That said we can be pluggable ;)

Le jeu. 30 août 2018 19:14, Raymond Auge <[hidden email]> a écrit :
Romain, you may not have seen this, but the OSGi Alliance worked on a (self-implemented) library (yes a non-OSGi library :) ) that might prove useful. It is very tiny so perhaps it could simply be embedded into the geronimo safeguard implementation.

Promises
=======
maven dep [1]
spec [2]

Considering the details of the fault tolerance specification (which honestly I have only read the readme ;) )
  • TimeOut: Define a duration for timeout
    Promises supports timeouts natively

  • RetryPolicy: Define a criteria on when to retry
    I think this is pretty easy to implement on Promises using a timeout + a fallback

  • Fallback: provide an alternative solution for a failed execution.
    Promises supports fallbacks natively

  • Bulkhead: isolate failures in part of the system while the rest part of the system can still function.
    If this is referring to executing tasks without blocking + callbacks + failure states, and such, then this is a native ability of Promises.

  • CircuitBreaker: offer a way of fail fast by automatically failing execution to prevent the system overloading and indefinite wait or timeout by the clients.
    Plenty of features to combine for this.

Just a thought!
- Ray




On Thu, Aug 30, 2018 at 6:00 AM, Romain Manni-Bucau <[hidden email]> wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Raymond Auge


On Thu, Aug 30, 2018 at 1:50 PM, Romain Manni-Bucau <[hidden email]> wrote:
failsafe as well but as a library (us/geronimo) we don't have guarantee it is stable and controlled and we had some "surprises". Question can be phrased as such "does the time to discuss if we can implement it is sufficient to implement it?", IMHO it is so we can just do it for one of the coming release.

I'll give you a simple example: commons-lang3 has some of these parts, but it is getting cut in N libraries which will grow independently which is the promise of N (N > 1) conflicts for us.
So since the cost to have it here is very low it does worth it IMHO and we own a full apache stack which is very valuable for the foundation IMHO.

Sure. makes sense!

- Ray
 
Now if the OSGi impl wants to donate it to ASF we can merge both.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 19:42, Raymond Auge <[hidden email]> a écrit :


On Thu, Aug 30, 2018 at 1:33 PM, Romain Manni-Bucau <[hidden email]> wrote:
Well, overall idea is to not conflict at all and stay light (stack generally are not worth it for these specs from my experience)

Oh, it's self implemented. i.e. you don't have N implementation. You simply use the utility library and doesn't need an OSGi framework at all. You can use it in plain Java.

- Ray
 
so I still think the original plan is ok and technically it is easy and enables us to make our ecosystem (asf with tomee, owb etc) consistent.

That said we can be pluggable ;)

Le jeu. 30 août 2018 19:14, Raymond Auge <[hidden email]> a écrit :
Romain, you may not have seen this, but the OSGi Alliance worked on a (self-implemented) library (yes a non-OSGi library :) ) that might prove useful. It is very tiny so perhaps it could simply be embedded into the geronimo safeguard implementation.

Promises
=======
maven dep [1]
spec [2]

Considering the details of the fault tolerance specification (which honestly I have only read the readme ;) )
  • TimeOut: Define a duration for timeout
    Promises supports timeouts natively

  • RetryPolicy: Define a criteria on when to retry
    I think this is pretty easy to implement on Promises using a timeout + a fallback

  • Fallback: provide an alternative solution for a failed execution.
    Promises supports fallbacks natively

  • Bulkhead: isolate failures in part of the system while the rest part of the system can still function.
    If this is referring to executing tasks without blocking + callbacks + failure states, and such, then this is a native ability of Promises.

  • CircuitBreaker: offer a way of fail fast by automatically failing execution to prevent the system overloading and indefinite wait or timeout by the clients.
    Plenty of features to combine for this.

Just a thought!
- Ray




On Thu, Aug 30, 2018 at 6:00 AM, Romain Manni-Bucau <[hidden email]> wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Bruno Baptista
In reply to this post by Romain Manni-Bucau

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_

Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
Dropping a lib looks big until it is done ;). Actually it will also allow us to drop all the bridge layers and builders which can make the lib way simpler for future contribution.

But no issue supporting 1.2 first.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 08:50, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_

Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Bruno Baptista

Thanks Romain!

On 07/09/2018 07:57, Romain Manni-Bucau wrote:
Dropping a lib looks big until it is done ;). Actually it will also allow us to drop all the bridge layers and builders which can make the lib way simpler for future contribution.

But no issue supporting 1.2 first.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 08:50, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_


Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
Hi guys,

Created a quick (actually took me 1h so not that quick :D) PoC to show what I have in mind for safeguard, long story short i just followed the points of this mail and put some "mock" code
to illustrate the idea enough (for instance the circuit breaker impl is not yet ready, it is just a simple fork of commons-lang flavor and all TCK are not passing).


I really the simplification it brings on the user land since everything becomes CDI and overriding any part of the runtime becomes easy now.
It also enables you to check why dropping failsafe is not scary.

I will probably try to make this branch passing - note that i upgraded the spec version so it misses some code, in particular regarding metrics - in the coming weeks.

Let me know what you think about that path and the alignment with all other impl we host.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 11:30, Bruno Baptista <[hidden email]> a écrit :

Thanks Romain!

On 07/09/2018 07:57, Romain Manni-Bucau wrote:
Dropping a lib looks big until it is done ;). Actually it will also allow us to drop all the bridge layers and builders which can make the lib way simpler for future contribution.

But no issue supporting 1.2 first.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 08:50, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_


Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Bruno Baptista

Hi Romain,

Sorry for not replying sooner.

That branch is a total rewrite of the project, the use of multiple interceptors is against the spec, Independently of considering the simple interceptor right or wrong. I see there is a MP issue debating that, but unless there's an obvious requirement to change it, I predict it will stay the same.

The PR goes against the ideas I had... Keep changes limited, keep the test separated, etc. It's frustrating for me, but I don't mind pointing the project in some other direction. My redline is to keep Failsafe.

Saying this, and because you seem to have came up with a masterplan of your own, could you please create some jira issues enabling other people to collaborate with your? Where do you want my help?

Regards.

On 25/11/18 19:15, Romain Manni-Bucau wrote:
Hi guys,

Created a quick (actually took me 1h so not that quick :D) PoC to show what I have in mind for safeguard, long story short i just followed the points of this mail and put some "mock" code
to illustrate the idea enough (for instance the circuit breaker impl is not yet ready, it is just a simple fork of commons-lang flavor and all TCK are not passing).


I really the simplification it brings on the user land since everything becomes CDI and overriding any part of the runtime becomes easy now.
It also enables you to check why dropping failsafe is not scary.

I will probably try to make this branch passing - note that i upgraded the spec version so it misses some code, in particular regarding metrics - in the coming weeks.

Let me know what you think about that path and the alignment with all other impl we host.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 11:30, Bruno Baptista <[hidden email]> a écrit :

Thanks Romain!

On 07/09/2018 07:57, Romain Manni-Bucau wrote:
Dropping a lib looks big until it is done ;). Actually it will also allow us to drop all the bridge layers and builders which can make the lib way simpler for future contribution.

But no issue supporting 1.2 first.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 08:50, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_


Reply | Threaded
Open this post in threaded view
|

Re: Safegard status

Romain Manni-Bucau
Hello Bruno,

Well this is not something new or a surprise, this is actually in the pipes since beginning of the year (I'd say March from memory but can be february when safeguard started to pass original TCK).
I waited for help on that topic proposed since months but since nobody wanted to lead that track I just picked it up last week.

On the help which can be needed:

- some cleanup on Future handling, currently the main interceptor (IdGeneratorInterceptor) does not handle futures but only CompletionStage (thanks cause it reminded me I had to open this issue on the spec -> https://github.com/eclipse/microprofile-fault-tolerance/issues/362).
- we can think to do as in other implementation and extract what can be extracted in a common library. I spent only very few time thinking of it but it seems the logic we can extract is quite specific to MP and not reusable that widely from my quick look (for example the circuit breaker of the spec is not that mainstream). That said another pair of eyes can be worth it.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 3 déc. 2018 à 11:41, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Sorry for not replying sooner.

That branch is a total rewrite of the project, the use of multiple interceptors is against the spec, Independently of considering the simple interceptor right or wrong. I see there is a MP issue debating that, but unless there's an obvious requirement to change it, I predict it will stay the same.

The PR goes against the ideas I had... Keep changes limited, keep the test separated, etc. It's frustrating for me, but I don't mind pointing the project in some other direction. My redline is to keep Failsafe.

Saying this, and because you seem to have came up with a masterplan of your own, could you please create some jira issues enabling other people to collaborate with your? Where do you want my help?

Regards.

On 25/11/18 19:15, Romain Manni-Bucau wrote:
Hi guys,

Created a quick (actually took me 1h so not that quick :D) PoC to show what I have in mind for safeguard, long story short i just followed the points of this mail and put some "mock" code
to illustrate the idea enough (for instance the circuit breaker impl is not yet ready, it is just a simple fork of commons-lang flavor and all TCK are not passing).


I really the simplification it brings on the user land since everything becomes CDI and overriding any part of the runtime becomes easy now.
It also enables you to check why dropping failsafe is not scary.

I will probably try to make this branch passing - note that i upgraded the spec version so it misses some code, in particular regarding metrics - in the coming weeks.

Let me know what you think about that path and the alignment with all other impl we host.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 11:30, Bruno Baptista <[hidden email]> a écrit :

Thanks Romain!

On 07/09/2018 07:57, Romain Manni-Bucau wrote:
Dropping a lib looks big until it is done ;). Actually it will also allow us to drop all the bridge layers and builders which can make the lib way simpler for future contribution.

But no issue supporting 1.2 first.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 7 sept. 2018 à 08:50, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Dropping failsafe altogether seems quite a big task, between re-implementation and testing. Would start on the support of Microprofile Fault Tolerance 1.2 right away and migrate bits of failsafe along the way, work for you guys?

Cheers.

On 30/08/2018 11:00, Romain Manni-Bucau wrote:
Hi Bruno,

Nothing crazy AFAIK, the only task I have in mind (but is not yet started) was to drop failsafe dependency to align this library on other geronimo ones (dep free)
and own the implementation.

Feel free to grab any task you want.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 30 août 2018 à 11:58, [hidden email] <[hidden email]> a écrit :
Hi,
I'm interested in contributing to Geronimo Safegard and help to add the new features in the upcoming Fault Tolerance 1.2 Spec.
Is there any work being executed or currently planed for this library?
Cheers!
--
Bruno Baptista
http://twitter.com/brunobat_