Recent changes to tickets

java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent

Hendy Irawan — Fri, 10 May 2013 12:46:33 -0000

When using de.huxhorn.lilith.logback.appender.ClassicMultiplexSocketAppender v 0.9.43 :

<configuration>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder 
            by default -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="multiplex" class="de.huxhorn.lilith.logback.appender.ClassicMultiplexSocketAppender">
        <Compressing>true</Compressing>
        <!-- will automatically use correct default port -->
        <!-- Default port for compressed is 10000 and uncompressed 10001 -->
        <ReconnectionDelay>10000</ReconnectionDelay>
        <IncludeCallerData>true</IncludeCallerData>
        <RemoteHosts>localhost</RemoteHosts>
        <!-- Alternatively:
        <RemoteHost>localhost</RemoteHost>
        <RemoteHost>10.200.55.13</RemoteHost>
        -->
        <!--
        Optional:
        <CreatingUUID>false</CreatingUUID>
        -->
    </appender>

    <logger name="org.apache.sshd" level="INFO" />
    <logger name="org.apache.directory.shared" level="INFO" />
    <logger name="org.apache.directory.api" level="INFO" />
    <logger name="org.apache.directory" level="INFO" />
    <logger name="org.apache.mina" level="INFO" />
    <logger name="org.apache.commons" level="INFO" />
    <logger name="CURSOR" level="INFO" />
    <logger name="org.springframework" level="INFO" />
    <logger name="id.co" level="DEBUG" />
    <logger name="org.soluvas" level="DEBUG" />
    <logger name="com.soluvas" level="DEBUG" />
    <logger name="com.hendyirawan" level="DEBUG" />
    <logger name="com.aksimata" level="DEBUG" />

    <root level="DEBUG">
        <!-- appender-ref ref="STDOUT" /-->
        <appender-ref ref="multiplex"/>
    </root>

</configuration>

Error message is as follows:

May 10, 2013 7:42:15 PM org.apache.catalina.core.ApplicationContext log
INFO: No Spring WebApplicationInitializer types detected on classpath
java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent
    at de.huxhorn.lilith.data.logging.protobuf.LoggingEventProtobufEncoder.convert(LoggingEventProtobufEncoder.java:388)
    at de.huxhorn.lilith.data.logging.protobuf.LoggingEventProtobufEncoder.encode(LoggingEventProtobufEncoder.java:76)
    at de.huxhorn.lilith.data.logging.protobuf.LoggingEventProtobufEncoder.encode(LoggingEventProtobufEncoder.java:54)
    at de.huxhorn.lilith.data.logging.logback.TransformingEncoder.encode(TransformingEncoder.java:112)
    at de.huxhorn.lilith.data.logging.logback.TransformingEncoder.encode(TransformingEncoder.java:46)
    at de.huxhorn.lilith.logback.appender.MultiplexSocketAppenderBase.append(MultiplexSocketAppenderBase.java:345)
    at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88)
    at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
    at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272)
    at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259)
    at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:441)
    at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:395)
    at ch.qos.logback.classic.Logger.log(Logger.java:787)
    at org.slf4j.bridge.SLF4JBridgeHandler.callLocationAwareLogger(SLF4JBridgeHandler.java:224)
    at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:301)
    at java.util.logging.Logger.log(Logger.java:565)
    at java.util.logging.Logger.doLog(Logger.java:586)
    at java.util.logging.Logger.logp(Logger.java:786)
    at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:185)
    at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:151)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:686)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:456)

Environment :

logback 1.0.12 / 1.0.11 (same error)

slf4j 1.7.5

Tomcat 7.0.39

Linux adri.dev 3.5.0-28-generic #48-Ubuntu SMP Tue Apr 23 23:03:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-0ubuntu0.12.10.1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Error does not happen with 0.9.42.1.

keyboard binding for copy Throwable

Scott Stanton — Wed, 07 Dec 2011 22:38:25 -0000

One of the most frequent actions I perform in looking at a log is to copy the Throwable from an error line so IntelliJ will display the stacktrace. It would be really helpful if there were a keyboard shortcut for this.

Add option for "wrapped exception style" in details view

Joern Huxhorn — Sat, 20 Aug 2011 12:25:50 -0000

Lilith should have an option to view exceptions in the (rather genius) "wrapped" style suggested by Tomasz Nurkiewicz in http://jira.qos.ch/browse/LBCLASSIC-217

I quote:

A typical exception in multi-tier application looks similar to this:

com.acme.BusinessException: Can't process request
at ...
at ...
Caused by: com.acme.dao.PersistenceException: Can't access database
at ...
at ...
... 49 common frames omitted
Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource
at ...
at ...
... 65 common frames omitted
Caused by: java.net.UnknownHostException: Unknown host localhostt
at ...
at ...
... 84 common frames omitted

The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive:

java.net.UnknownHostException: Unknown host localhostt
at ...
at ...
Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database
at ...
at ...
Wrapped by: com.acme.dao.PersistenceException: Can't access database
at ...
at ...
Wrapped by: com.acme.BusinessException: Can't process request
at ...
at ...

It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top.

and accepts partial or wildcarded IPs?

Jeff Jensen — Mon, 08 Aug 2011 19:49:03 -0000

The Lilith online help shows:

<RemoteHosts>localhost, 10.200.55.13</RemoteHosts>

Without digging into code (resulting in viewing InetAddress.getAllByName), one doesn't easily know if wildcards will work or not, e.g. 10.200.. or just 10.200. I suggest adding the info to the doc page.

Create snapshots with packaging similar to releases

Jeff Jensen — Tue, 19 Jul 2011 18:24:27 -0000

Since we use the Lilith snapshots for quite awhile, is a nice-to-have for the users to unzip/unjar the snapshot and run the lilith.bat file just as for releases vs interested users creating their own or manually starting from command line with java -jar lilith.jar.

After many runs that replace opened log file, Updating task fails with "Negative seek offset"

Jeff Jensen — Fri, 27 May 2011 19:29:24 -0000

Similar to #88, if Lilith has a .lilith log file open and the log file is replaced with each run (use case is developing integration tests and using Lilith to monitor the log file), eventually Lilith fails with "Execution of task Updating: xxx.lilith failed! Negative seek offset."

If I restart Lilith, it prompts "Index file does not exist! Index data file right now?" but then errors with the following when doing so: "Execution of task Indexing Lilith file failed! Negative seek offset".

I have to delete the .lilith log file and restart Lilith to recover.
Only using "Clean all inactive logs" doesn't fix the problem - Lilith will error with the negative seek offset problem when trying to open the file and create the index.

Tomcat reports memory leaks when using ClassicMultiplexSocketAppender

Andy Goossens — Sat, 30 Apr 2011 16:01:55 -0000

I have a web application which I deploy in Tomcat 7.0.12. This application uses Lilith's ClassicMultiplexSocketAppender and Logback's RollingFileAppender.

When I stop my application, Tomcat reports it found some (possible) memory leaks. When I am not using ClassicMultiplexSocketAppender it reports none.

Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/myApplication] appears to have started a thread named [SendBytes@SocketDataOutputStreamFactory[hostName=localhost, port=10001, connectionTimeout=10000, writeTimeout=5000]] but has failed to stop it. This is very likely to create a memory leak.
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/myApplication] appears to have started a thread named [lilithMultiplex Dispatcher] but has failed to stop it. This is very likely to create a memory leak.
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/myApplication] appears to have started a thread named [lilithMultiplex Heartbeat] but has failed to stop it. This is very likely to create a memory leak.
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/myApplication] appears to have started a thread named [Reconnection@SocketDataOutputStreamFactory[hostName=localhost, port=10001, connectionTimeout=10000, writeTimeout=5000]] but has failed to stop it. This is very likely to create a memory leak.
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/myApplication] appears to have started a thread named [TimeoutOutputStream Watchdog-Thread] but has failed to stop it. This is very likely to create a memory leak.
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/myApplication] created a ThreadLocal with key of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.CloningNdcStackThreadLocal] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$CloningNdcStackThreadLocal@1ff83]) and a value of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.NdcStack] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$NdcStack@12e0e2f]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/myApplication] created a ThreadLocal with key of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.CloningNdcStackThreadLocal] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$CloningNdcStackThreadLocal@1ff83]) and a value of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.NdcStack] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$NdcStack@a53564]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
Apr 30, 2011 5:49:05 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/myApplication] created a ThreadLocal with key of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.CloningNdcStackThreadLocal] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$CloningNdcStackThreadLocal@1ff83]) and a value of type [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter.NdcStack] (value [de.huxhorn.lilith.logback.classic.SimpleNDCAdapter$NdcStack@54782a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

Popup menu not updated properly in case of detached window

Joern Huxhorn — Wed, 26 Jan 2011 14:58:31 -0000

Workaround: Use copy actions from the menubar in the meantime.

Found by Dimi.

Add rolling support for file appender

Daniel Harvey — Wed, 18 Aug 2010 08:32:24 -0000

Currently, the file based appender for lilith just grows in size.

It would be good to add rolling support for this appender.

Automagical "Find previous"/"Find next"

Joern Huxhorn — Thu, 01 Jul 2010 08:24:09 -0000

Implement another next/prev that jumps to the next/prev event matching any of the saved conditions.