logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Coe <rcoe.java...@gmail.com>
Subject Re: JSONLayout serializes the MDC as a List<Map<String,String>>?
Date Tue, 12 Jan 2016 16:34:27 GMT
I would be happy to test but haven't looked at the writer implementations,
so speedy would not be the effort.  But, it's a performance issue
only...maybe...so no hurry anyway.

On Tue, Jan 12, 2016 at 11:30 AM, Gary Gregory <garydgregory@gmail.com>
wrote:

> If the reason to do this is performance, it should be proved by a
> benchmark...
>
> Gary
> On Jan 12, 2016 8:28 AM, "Gary Gregory" <garydgregory@gmail.com> wrote:
>
>> Maybe something like mdcStyle="this/that/future"?
>>
>> This would also apply to the XML layout?
>>
>> Gary
>> On Jan 12, 2016 8:26 AM, "Mikael Ståldal" <mikael.staldal@magine.com>
>> wrote:
>>
>>> Ah yes, that's possible. It would be nice.
>>>
>>> On Tue, Jan 12, 2016 at 5:24 PM, Ralph Goers <ralph.goers@dslextreme.com
>>> > wrote:
>>>
>>>> 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 <mikael.staldal@magine.com>
>>>> 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 <rcoe.javadev@gmail.com>
>>>> 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 <
>>>>> mikael.staldal@magine.com> 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
>>>>>>
>>>>>> Perhaps GELFLayout would work better for you.
>>>>>>
>>>>>> On Mon, Jan 4, 2016 at 10:00 PM, Gary Gregory <garydgregory@gmail.com
>>>>>> > 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" <rcoe.javadev@gmail.com>
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 <
>>>>>>>> garydgregory@gmail.com> 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" <rcoe.javadev@gmail.com>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [image: MagineTV]
>>>>>>
>>>>>> *Mikael Ståldal*
>>>>>> Senior software developer
>>>>>>
>>>>>> *Magine TV*
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   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.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   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.
>>>
>>

Mime
View raw message