Safegard status

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

Safegard status

brunobat@gmail.com
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

brunobat@gmail.com
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

brunobat@gmail.com

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_