Usage Question about logparser

[nielsbasjes]

1. The root cause of the parse error is that in the regex I generate I expect the firstline to look like this:
   (?:[a-zA-Z-_]+ .*(?: HTTP/[0-9]+\\.[0-9]+)?)|-

The value \x16\x03\x01 does not match that pattern so the parsing for that line fails.
I just had a look and I think I fixed it (it now allows the firstline to be .*).
Can you verify please?

2. The code you posted looks fine and is how I intended it to be used.
   I ran this code by simply parsing the same line 2146891 times and this took approx 48 seconds on my laptop (i7). So yes, slower but not that slow.

Yes, internally I generate a regex for the first parsing layer.
You got to see it as part of the error in the previous question.

The regex is created as 'tightly as possible'. So for example for the IP address the regex is quite elaborate because I want to trip the 'wrong format' situation an still allow both ipv4 and ipv6. This system is slower than 'just a regex' and perhaps there is room to make it faster. Yet this is one of those balances between 'ease of use' vs 'maximum speed'.

[nielsbasjes]

One remark on the way you use the code: The parser will ONLY call the setter if it actually has the field.
So if you extract a field that is sometimes present and sometimes it is not you may have 'old values' in your record.
I recommend you include a method to clear the values before you pass it again into the parser.

If for example I add this

        @Field("HTTP.METHOD:request.firstline.method")
        public void setMethod(String method) {
            this.method = method;
        }

And then first call it with the 'normal firstline' and the with the "\x16\x03\x01" I would see in both records the method being "GET". In the first record it was extracted, in the second record it was not there so nothing was set and the old value wat not overwritten.

[java8964]

Yes. This issue is gone in version of 3.1-SNAPSHOT from master. When do you plan to release it? For the performance, we may use this library as a additional logic to parse the data if the plan REGEX cannot handle it, so it won't impact the performance too much

[nielsbasjes]

I just released version 3.1 that includes these changes.
Should be in maven central in a few hours or so.