Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Benedikt Ritter
Hi Oliver, Oliver Heger schrieb am So., 12. Juni 2016 um 16:52 Uhr: > The current implementations that we have a pretty generic and just track > memory consumption or count events (e.g. failed service invocations). > They are not tighed to any specific use case or

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Oliver Heger
The current implementations that we have a pretty generic and just track memory consumption or count events (e.g. failed service invocations). They are not tighed to any specific use case or domain. I think, [lang] is a good fit, but maybe the classes can be moved to a separate package?

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Pascal Schumacher
I have only see it used to prevent cascading failures in distributed systems (see http://martinfowler.com/bliki/CircuitBreaker.html for a detailed explanation). Hystrix and Apache Camel contain implementations of this pattern. Am 12.06.2016 um 14:17 schrieb James Carman: Can it be used in

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread James Carman
Can it be used in non-I/O situations? On Sun, Jun 12, 2016 at 8:15 AM sebb wrote: > IO is a better fit than NET, but I'm not sure that it is better than LANG. > > On 12 June 2016 at 13:03, James Carman wrote: > > It has general stream/reader stuff

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread sebb
IO is a better fit than NET, but I'm not sure that it is better than LANG. On 12 June 2016 at 13:03, James Carman wrote: > It has general stream/reader stuff too. > > On Sun, Jun 12, 2016 at 7:53 AM Benedikt Ritter wrote: > >> Pascal Schumacher

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread James Carman
It has general stream/reader stuff too. On Sun, Jun 12, 2016 at 7:53 AM Benedikt Ritter wrote: > Pascal Schumacher schrieb am So., 12. Juni 2016 > um 13:50 Uhr: > > > Yes, so I guess Commons IO would be the best fit. > > > > Really? When talking

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Benedikt Ritter
Pascal Schumacher schrieb am So., 12. Juni 2016 um 13:50 Uhr: > Yes, so I guess Commons IO would be the best fit. > Really? When talking about I/O I always think about file system operations... > > Am 12.06.2016 um 13:40 schrieb James Carman: > > Is it only I/O

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Pascal Schumacher
Yes, so I guess Commons IO would be the best fit. Am 12.06.2016 um 13:40 schrieb James Carman: Is it only I/O related? On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter wrote: Hi, CircuitBreaker is a pattern usually used when working with remote systems. We have a

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Benedikt Ritter
sebb schrieb am So., 12. Juni 2016 um 13:33 Uhr: > On 12 June 2016 at 12:05, Benedikt Ritter wrote: > > Hi, > > > > CircuitBreaker is a pattern usually used when working with remote > systems. > > We have a CircuitBreaker implementation added to [LANG] in

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread James Carman
Is it only I/O related? On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter wrote: > Hi, > > CircuitBreaker is a pattern usually used when working with remote systems. > We have a CircuitBreaker implementation added to [LANG] in the concurrent > package. Now I'm wondering

Re: [LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread sebb
On 12 June 2016 at 12:05, Benedikt Ritter wrote: > Hi, > > CircuitBreaker is a pattern usually used when working with remote systems. > We have a CircuitBreaker implementation added to [LANG] in the concurrent > package. Now I'm wondering whether it would better fit into

[LANG] Would CircuitBreaker better fit into [NET]?

2016-06-12 Thread Benedikt Ritter
Hi, CircuitBreaker is a pattern usually used when working with remote systems. We have a CircuitBreaker implementation added to [LANG] in the concurrent package. Now I'm wondering whether it would better fit into [NET]. Thoughts? Benedikt