brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
Subject Re: <contents-garbage-collected>
Date Wed, 17 May 2017 11:01:22 GMT
Hi Richard.

I'm really happy that you bring this topic because it did happen to me in
the past and becomes more and more frequent now that we are running
Brooklyn in Karaf.
AFAIK, the only way to get this information back is to scan the Brooklyn
debug log but it neither easy or ideal. You could setup an ELK stack to
process the logs but again, that means setup something external which we
don't advocate for.

>From a personal point of view, I really think it's a big flaw in Brooklyn
because:

   1. you loose very important data over time
   2. even worse, this data is not persisted so if you restart brooklyn,
   it's just gone

Typically, I would be wary to use it in production if I cannot quickly
debug what is going on from the UI/CLI.

I think that shipping Brooklyn with an embedded datastore would be a good
solution to solve this. I would lean toward elasticsearch for this but we
could choose something else (such as cassandra) if we want to be 100%
Apache.

Best.

On Wed, 17 May 2017 at 11:41 Richard Downer <richard@apache.org> wrote:

> I see to be seeing this:
>
> <contents-garbage-collected>
>
> a lot recently, when I inspect stdin/stdout/stderr of a failed task. Often
> I never have a chance to see the contents even if I go to look at a failed
> task as soon as it fails.
>
> Is there any way I can extend the availability of this data, or prevent it
> from being garbage collected?
>
> Thanks
> Richard
>
-- 

Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message