If there is a flag that causes the new structure to be generated then he would get the performance gain when it is enabled. The current structure would be generated when the flag is not set.
Ralph > On Jan 12, 2016, at 9:14 AM, Mikael Ståldal <[email protected]> wrote: > > But I guess that you won't get any performance gain if we keep the old > structure besides the new one, since then both will be parsed. > > On Tue, Jan 12, 2016 at 3:15 PM, Robin Coe <[email protected] > <mailto:[email protected]>> wrote: > I agree that if it were changed there may be some compatibility issues. But, > if it's doable, then introducing a new property could bridge the change. Not > saying it's doable, because I haven't looked, but a new property and a > deprecation warning (in docs, I expect) would allow the change to happen. > Very preliminary data showed me that parsing 1000 events slowed my parser > from < 500 ms (w/o contextMap) to 2000 ms when each event contained 2 > contextMap entries, requiring the list of maps to be converted to a single > map. Not sure what the time would be to parse a multi-valued map, though, so > I can't be sure of the overhead of walking the list wrapper. > > On Tue, Jan 12, 2016 at 6:05 AM, Mikael Ståldal <[email protected] > <mailto:[email protected]>> wrote: > I think that the current JSONLayout format is unfortunate, and I would prefer > to have it as you propose. But we cannot change it now since that will break > backwards compatibility. > > See: https://issues.apache.org/jira/browse/LOG4J2-623 > <https://issues.apache.org/jira/browse/LOG4J2-623> > > Perhaps GELFLayout would work better for you. > > On Mon, Jan 4, 2016 at 10:00 PM, Gary Gregory <[email protected] > <mailto:[email protected]>> wrote: > The point I was trying to make is that you cannot describe what you are > asking for with a generic XML schema, not sure about JSON schema, but the > idea is the same. Since we use Jackson, that also means we use the same code > to emit JSON and XML. > > Gary > > On Jan 4, 2016 12:25 PM, "Robin Coe" <[email protected] > <mailto:[email protected]>> wrote: > I can see that XML entities requires conforming to a schema but isn't the > writer implementation capable of wrapping the map entries when required? > Seems like it's making the JSON representation more complex (and less > performant) at the cost of some wrapper code for the xml writer. > > On Mon, Jan 4, 2016 at 3:19 PM, Gary Gregory <[email protected] > <mailto:[email protected]>> wrote: > Yes, that is because we can define this kind of structure with XML/JSON > schema with ease. > > Gary > > On Jan 4, 2016 11:55 AM, "Robin Coe" <[email protected] > <mailto:[email protected]>> wrote: > I was trying to deserialize a log event written by the JSONLayout appender, > which uses Jackson. I therefore also am using Jackson but with the > MrBeanModule, which is a POJO materializer. After much difficulty with > Jackson throwing deserialization exceptions with the "contextMap" field, I > learned that the map is actually written out as a List of Maps (i.e. > List<Map<String,String>>. I've included one such event here, with > unnecessary fields shortened: > > {"timeMillis":...,"thread":"...","level":"OFF","loggerName":"...","message":"...","endOfBatch":false,"loggerFqcn":"...","contextMap":[{"key":"LOGROLL","value":"com.xxx.xxx.handler.event.FailoverHandler"},{"key":"ROUTINGKEY","value":"elasticsearch-rollover"}]} > > I'm curious why the contextMap is represented as the more complex List of > single entry Maps, as opposed to a single multi-valued Map? So, instead of > something that looks like: > > > {"contextMap":[{"key":"key1"},{"value":"value1"},{"key":"key2"},{"value":"value2"},...] > > I would expect the much simpler (and easily parseable): > {"contextMap":{"key1":"value1","key2":"value2",...}. > > Is this intended? > > Thanks, > Robin. > > > > > -- > > > Mikael Ståldal > Senior software developer > > Magine TV > [email protected] <mailto:[email protected]> > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > <http://www.magine.com/> > > Privileged and/or Confidential Information may be contained in this message. > If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply email. > > > > > > -- > > > Mikael Ståldal > Senior software developer > > Magine TV > [email protected] <mailto:[email protected]> > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > <http://www.magine.com/> > > Privileged and/or Confidential Information may be contained in this message. > If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply email. >
