On Fri, Oct 26, 2018 at 7:03 AM Volkan Yazıcı <[email protected]> wrote: > > I can see that JsonGenerator keeps the door open for further input, that > indeed allows me to reuse it. (Thanks for the "root value separator" config, > did not know about it.) But that is also the reason I need to reach for > rescueJsonGeneratorState(). It would be really nice if I could have somehow > "reset" the state of JsonGenerator (which is actually Utf8JsonGenerator in > this particular case) and FilteringGeneratorDelegate. Then before each > serialization attempt, I can just reset my BB+generators and am ready to go.
It would probably be easier to allow resetting of delegate type, but less so for regular generators. But I am still bit unclear on specific need: what part are you specifically hoping to reset? If it'd be output state (which Object/Array open etc), only close() would change that. But if you are thinking of underlying destination (OutputStream, Writer), buffering, those are not designed to be changed, and I wouldn't want to change that. Then again, if resetting of delegate (by changing target) was enough, that might be easy enough. -+ Tatu +- > On Friday, October 26, 2018 at 3:57:38 AM UTC+2, Tatu Saloranta wrote: >> >> On Wed, Oct 24, 2018 at 5:35 AM Volkan Yazıcı <[email protected]> wrote: >> > >> > I am at the edge of making log4j2-logstash-layout gc-free. And at >> > this stage my only (GC) obstacle is the aforementioned two classes. >> > I need to instantiate them at each encode(LogEvent) call and this >> > spoils the entire gc-free magic. >> > >> > What I can do is create a ThreadLocal parade of >> > ByteBufferOutputStream->JsonGenerator->FilteringGeneratorDelegate. >> > This allows me to implement encode() as follows: >> > >> > get ThreadLocal resources >> > reset BBOS >> > writeStartObject() >> > encode fields >> > writeEndObject() >> > flip and drain the BBOS to the Log4j BB sink >> > >> > Though this approach has an unfortunate showstopper: If the 4th step >> > leaves the JsonGenerator and/or the FilteringGeneratorDelegate in a >> > dirty state -- consider exceeding BBOS capacity, etc. -- all the >> > subsequent calls will fail. >> > >> > I will deeply appreciate any kind of help on this issue. >> >> Ah ok. Thank you for providing more information. This sounds like an >> interesting and useful challenge. :) >> I like to ask these things ("is that really necessary") first as I >> often learn something new. >> >> One thing that may be worth mentioning in case you weren't aware: you >> can just leave `JsonGenerator` open: >> it does not enforce that content consists of just a single JSON Value. >> In fact this is how many stream data generation >> (and parsing, via JsonParser) systems work. >> There is separate "root value separator" that is used between root >> values: it defaults to " " (single space), but may be >> reconfigured to, for example, linefeed. >> >> Whether this will work with FilteringGeneratorDelegate is bit >> different question. >> >> But do you think that reuse by not closing would work from processing >> perspective. >> >> -+ Tatu +- >> >> >> >> >> > >> > Best. >> > >> > On Monday, October 22, 2018 at 6:59:02 AM UTC+2, Tatu Saloranta wrote: >> >> >> >> On Sun, Oct 21, 2018 at 2:02 PM Volkan Yazıcı <[email protected]> wrote: >> >> > >> >> > Hi, >> >> > >> >> > I have a JsonGenerator and FilteringGeneratorDelegate usage as follows: >> >> > >> >> > ByteArrayOutputStream outputStream = threadLocalOutputStreamRef.get(); >> >> > try (JsonGenerator jsonGenerator = >> >> > jsonFactory.createGenerator(outputStream)) { >> >> > try (JsonGenerator jsonGeneratorDelegate = new >> >> > FilteringGeneratorDelegate(jsonGenerator, tokenFilter, true, true)) { >> >> > // ... >> >> > } >> >> > } >> >> > >> >> > Is it possible to reuse JsonGenerator and FilteringGeneratorDelegate >> >> > instances in a way attached to the local thread context? >> >> >> >> No, JsonGenerator is designed for use-once life-cycle and does not >> >> support reuse. >> >> Instances are light-weight so there shouldn't usually be much benefit >> >> from attempting to reuse instances; same goes with >> >> FilteringGeneratorDelegate. >> >> >> >> -+ Tatu +- >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "jackson-user" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
