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?
Oliver
Am 12.06.2016 um 14:37 schrieb 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 non-I/O situations?
On Sun, Jun 12, 2016 at 8:15 AM sebb <seb...@gmail.com> 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 <ja...@carmanconsulting.com>
wrote:
It has general stream/reader stuff too.
On Sun, Jun 12, 2016 at 7:53 AM Benedikt Ritter <brit...@apache.org>
wrote:
Pascal Schumacher <pascalschumac...@gmx.net> 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 related?
On Sun, Jun 12, 2016 at 7:05 AM Benedikt Ritter <brit...@apache.org
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 [NET].
Thoughts?
Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
