logback module about rollbar-java HOT 9 CLOSED

@mabn sounds great!

from rollbar-java.

@brianr
It seems that the issue with numbers in class/method names remains.

I have following frame in stack traces (not only this one, there are others):

47 at com.getbase.services.feeder.services.FeedService$$Lambda$171/2132586099.apply (Unknown source)

The problem is that it completely beats the default fingerprinting algorithm and whenever the numbers change (and they change from time to time) the exceptions are reported under a new category. Previously I solved it by implementing own fingerprinter which removes all numbers from class and method names (https://github.com/fstech/rollbar-logback/blob/master/src/main/java/com/tapstream/rollbar/fingerprinter/CustomFingerprinter.java#L71).

What's the best approach to this? Should it be included here as well? (if so - any suggestions where to put it?) Or is it something that Rollbar could handle on the server side?

There's also that "Custom Grouping" setting on the frontend, but I don't think it's robust enough.

from rollbar-java.

@mabn I think the right thing to do would be for Rollbar to normalize/strip out the numbers server-side.

Can you provide a few more examples?

Based on the one you showed, I'm guessing we will want to normalize that to the following:

com.getbase.services.feeder.services.FeedService$$Lambda$*/*.apply

(match on $$Lambda$ being in the string, then replace any integers from there to the end of the line with a single *)

from rollbar-java.

Some more examples:

com.getbase.common.buava.operation.OperationTracker$$Lambda$135/2085968933.accept

com.getbase.common.buava.multithreadflow.wrapper.MultiThreadFlowCallableWrapper$$Lambda$128/1715254294.callWith (Unknown source)

java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301 (ScheduledThreadPoolExecutor.java:180)

com.getbase.SomeClass$$FastClassBySpringCGLIB$$1393a903.invoke (Unknown source)

19 at com.getbase.SomeClass$$EnhancerBySpringCGLIB$$63fd98b0.query (Unknown source)
20 at sun.reflect.GeneratedMethodAccessor58.invoke (Unknown source)
21 at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)

// this one is not special, but has '$$' without numbers, but in the method name this time:
kafka.producer.SyncProducer.kafka$producer$SyncProducer$$doSend (SyncProducer.scala:72) 

Given that cglib also uses $$ it might be a good idea to replace everything after "$$" in the class name - that this will always be some autogenerated code which (I believe) could be completely skipped.

A blog post with some context: http://blog.takipi.com/the-dark-side-of-lambda-expressions-in-java-8/

from rollbar-java.

One more thing - it seems that the behaviour has changed between jdk8u45 and jdk8u65 and now that frame with something$$Lambda$135/2085968933.method (Unknown Source) is gone.
That's why I wasn't able to reproduce it on my laptop.

from rollbar-java.

@brianr any news on this? We're seeing a lot of duplicates due to this issue.

For example:
at testMethod (com.domain.package.TestController$$EnhancerBySpringCGLIB$$b7a2f393.java:-1)
and
at testMethod (com.domain.package.TestController$$EnhancerBySpringCGLIB$$1e8838b4.java:-1)

Ignoring anything after two dollar signs $$ would work, since it would ignore classes that were dynamically generated at runtime.

from rollbar-java.

Bump.

from rollbar-java.

I have created an internal task to handle this on the backend so that anything after two dollar signs will be ignored. I will update this task as that progresses.

from rollbar-java.

@rokob Is this still relevant?

from rollbar-java.