lilith-devel Mailing List for lilith
Brought to you by:
huxhorn
You can subscribe to this list here.
2009 |
Jan
(23) |
Feb
(29) |
Mar
(55) |
Apr
(26) |
May
(12) |
Jun
(18) |
Jul
(21) |
Aug
(19) |
Sep
(41) |
Oct
(63) |
Nov
(14) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
(12) |
May
(45) |
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(3) |
Feb
(2) |
Mar
(1) |
Apr
(7) |
May
(12) |
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: lilith - T. i. <no...@so...> - 2013-05-10 19:29:46
|
#102: java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent ------------------------------+--------------------------------------------- Reporter: ceefour | Owner: huxhorn Type: defect | Status: closed Priority: major | Milestone: unclassified Component: lilith-appender | Version: 0.9.43 Resolution: invalid | Keywords: ------------------------------+--------------------------------------------- Comment(by huxhorn): You are very welcome. :) Glad your problem was solved. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/102#comment:4> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2013-05-10 19:28:03
|
#102: java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent ------------------------------+--------------------------------------------- Reporter: ceefour | Owner: huxhorn Type: defect | Status: closed Priority: major | Milestone: unclassified Component: lilith-appender | Version: 0.9.43 Resolution: invalid | Keywords: ------------------------------+--------------------------------------------- Changes (by ceefour): * status: new => closed * resolution: => invalid Comment: Thanks ! Indeed it's a conflict, protobuf 2.5.0 fixed the problem -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/102#comment:3> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2013-05-10 14:36:59
|
#102: java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent -----------------------------+---------------------------------------------- Reporter: ceefour | Owner: huxhorn Type: defect | Status: new Priority: major | Milestone: unclassified Component: lilith-appender | Version: 0.9.43 Keywords: | -----------------------------+---------------------------------------------- Comment(by huxhorn): Sounds like there is some protobuf version snafu. Is it possible that there is a protobuf version < 2.5.0 in the classpath? -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/102#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2013-05-10 12:47:43
|
#102: java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent -----------------------------+---------------------------------------------- Reporter: ceefour | Owner: huxhorn Type: defect | Status: new Priority: major | Milestone: unclassified Component: lilith-appender | Version: 0.9.43 Keywords: | -----------------------------+---------------------------------------------- Comment(by ceefour): Error does not happen with **lilith appender** 0.9.42.1. The lilith GUI app version does not matter. (I'm using lilith app GUI 0.9.43 and it works with appender 0.9.41) -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/102#comment:1> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2013-05-10 12:46:36
|
#102: java.lang.VerifyError: de/huxhorn/lilith/data/logging/protobuf/generated/LoggingProto$LoggingEvent -----------------------------+---------------------------------------------- Reporter: ceefour | Owner: huxhorn Type: defect | Status: new Priority: major | Milestone: unclassified Component: lilith-appender | Version: 0.9.43 Keywords: | -----------------------------+---------------------------------------------- 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. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/102> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2012-08-06 17:42:13
|
#77: maximize new session windows by default -------------------------+-------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: defect | Status: reopened Priority: minor | Milestone: unclassified Component: lilith-app | Version: 0.9.42 Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment(by snstanton): The only thing that shows up in the lilith log is: {{{ de.huxhorn.lilith.engine.impl.eventproducer.AbstractStreamEventProducer ste://de.huxhorn.lilith.engine.impl.eventproducer.AbstractStreamEventProducer$ReceiverRunnable.run(AbstractStreamEventProducer.java:100) Exception (java.net.SocketException: 'Connection reset') while reading events. Adding eventWrapper with empty event and stopping... }}} Also, it doesn't appear to be random. It reliably alternates between maximized and not between successive runs. It seems to affect all windows at the same time, too. If I have the lilith log open and maximized, when the new connection comes in, both the new window and the lilith window alternate between maximized and normal. So on successive runs, both windows maximize one time and revert to normal the next. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/77#comment:9> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2012-08-05 22:43:01
|
#77: maximize new session windows by default -------------------------+-------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: defect | Status: reopened Priority: minor | Milestone: unclassified Component: lilith-app | Version: 0.9.42 Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment(by huxhorn): What happens if you click on "Log all!" in the Debug dialog that is hidden in the Help menu? Is it the same in that case? Are the windows opened with maximize turned on only randomly? I'm seriously stuck with this one... My last Windows machine just died so I'm unable to test on that platform anymore. But I never heard about this from any of my Windows coworkers that are using Lilith. Sorry that I can't help you at the moment. :( -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/77#comment:8> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2012-07-25 17:23:48
|
#77: maximize new session windows by default -------------------------+-------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: defect | Status: reopened Priority: minor | Milestone: unclassified Component: lilith-app | Version: 0.9.42 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by snstanton): * status: closed => reopened * resolution: worksforme => * priority: major => minor * version: 0.9.37 => 0.9.42 * milestone: M6 => unclassified * type: enhancement => defect Comment: I'm still having this problem. It appears to alternate such that ever other connection opens maximized. The settings I'm using are: {{{ Show toolbar: yes show statusbar: yes use internal frames: yes maximize internal frames: yes automatically open new views on connection: yes automatically focus window of new view: no automatically close inactive views on disconnection: yes (although I've tried both ways and it makes no difference) show identifier for named sources: yes }}} There aren't any interesting messages in the lilith log. I'm connecting via logback with the following config: {{{ <appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender"> <param name="port" value="4560"/> <param name="remoteHost" value="localhost"/> </appender> }}} Is there any additional logging in lilith you would like me to enable to help track this down? -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/77#comment:7> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2012-03-11 22:02:55
|
#99: <RemoteHosts> and <RemoteHost>accepts partial or wildcarded IPs? -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: new Priority: minor | Milestone: M10 Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- Changes (by huxhorn): * milestone: M9 => M10 -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/99#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2012-01-08 17:49:55
|
#101: keyboard binding for copy Throwable --------------------------+------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: enhancement | Status: closed Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by huxhorn): * status: assigned => closed * resolution: => fixed Comment: Fixed in @fed7d18c45c5208f8657f5db4a3702bc79955d4f. "Copy Throwable" does now have the shortcut "command shift alt T". (Sorry, it had to be so complicated to prevent a clash.) -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/101#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-12-07 22:48:14
|
#101: keyboard binding for copy Throwable -------------------------+-------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: enhancement | Status: assigned Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- Changes (by huxhorn): * status: new => assigned * milestone: unclassified => M9 Comment: I will add this. Are you aware of the Lilith plugin for IDEA? You can simply click on any !StackTraceElement and the corresponding source will open in IDEA if it is available in the current project. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/101#comment:1> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-12-07 22:38:30
|
#101: keyboard binding for copy Throwable -------------------------+-------------------------------------------------- Reporter: snstanton | Owner: huxhorn Type: enhancement | Status: new Priority: major | Milestone: unclassified Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- 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. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/101> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-08-23 21:58:43
|
#100: Add option for "wrapped exception style" in details view --------------------------+------------------------------------------------- Reporter: huxhorn | Owner: huxhorn Type: enhancement | Status: closed Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by huxhorn): * status: new => closed * resolution: => fixed Comment: Fixed in @d088b4b0532104013fbdb32ff76919f3d4c8d704. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/100#comment:1> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-08-20 12:25:50
|
#100: Add option for "wrapped exception style" in details view -------------------------+-------------------------------------------------- Reporter: huxhorn | Owner: huxhorn Type: enhancement | Status: new Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- 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. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/100> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-08-20 12:14:07
|
#99: <RemoteHosts> and <RemoteHost>accepts partial or wildcarded IPs? -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: new Priority: minor | Milestone: M9 Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- Changes (by huxhorn): * milestone: unclassified => M9 -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/99#comment:1> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-08-08 19:49:07
|
#99: <RemoteHosts> and <RemoteHost>accepts partial or wildcarded IPs? -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: new Priority: minor | Milestone: unclassified Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- 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. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/99> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-07-22 01:53:01
|
#98: Create snapshots with packaging similar to releases --------------------------+------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: closed Priority: minor | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Comment(by jeffjensen): You are the best. If only you were near so I could buy you many-a-beer. :) -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/98#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-07-21 22:47:36
|
#98: Create snapshots with packaging similar to releases --------------------------+------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: closed Priority: minor | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by huxhorn): * status: new => closed * resolution: => fixed * milestone: unclassified => M9 Comment: Your wish is my command. ;) I just released a new snapshot with the same binary packagings as the releases. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/98#comment:1> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-07-19 18:24:31
|
#98: Create snapshots with packaging similar to releases -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: enhancement | Status: new Priority: minor | Milestone: unclassified Component: lilith-app | Version: 0.9.41 Keywords: | -------------------------+-------------------------------------------------- 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. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/98> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-07-01 16:19:28
|
#97: After many runs that replace opened log file, Updating task fails with "Negative seek offset" -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: defect | Status: closed Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Comment(by jeffjensen): With 0.9.42-SNAPSHOT, I have not seen this error occur again with two processes writing to the same .lilith log file. I now see your change, the regular "Could not load event!" message: and "Exception while reindexing log file. Ignoring it..." messages in the log... and no problems resulting. The viewer initially displays the content from one of the two processes, then often remains blank until one process completes and then the remaining process items display (I think for new messages only; not sure). I'm not sure if this behavior is due to the file having two processes write to it, or is there a reading or refresh problem. The improvement is that I no longer have to restart Lilith for this problem. Thanks! :-) (and when I begin encountering this problem, I disable Infinitest... the obvious ;-) -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/97#comment:5> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-06-26 22:33:53
|
#52: "Exclude" and "Focus" context submenus. --------------------------+------------------------------------------------- Reporter: huxhorn | Owner: huxhorn Type: enhancement | Status: closed Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.34 Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by huxhorn): * status: assigned => closed * resolution: => fixed Comment: Fixed in @091b9cabbd356617b35d4c019893d707bf779215. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/52#comment:3> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-06-26 17:58:42
|
#52: "Exclude" and "Focus" context submenus. -------------------------+-------------------------------------------------- Reporter: huxhorn | Owner: huxhorn Type: enhancement | Status: assigned Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.34 Keywords: | -------------------------+-------------------------------------------------- Changes (by huxhorn): * status: new => assigned * milestone: unclassified => M9 -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/52#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-06-15 06:27:27
|
#97: After many runs that replace opened log file, Updating task fails with "Negative seek offset" -------------------------+-------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: defect | Status: closed Priority: major | Milestone: M9 Component: lilith-app | Version: 0.9.41 Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by huxhorn): * status: assigned => closed * resolution: => fixed * milestone: unclassified => M9 Comment: Fixed in 7d4ab3d8ea035cf95db1b91ec1f3037b3ff66051. -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/97#comment:4> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-05-29 15:14:29
|
#97: After many runs that replace opened log file, Updating task fails with "Negative seek offset" ------------------------+--------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: defect | Status: assigned Priority: major | Milestone: unclassified Component: lilith-app | Version: 0.9.41 Keywords: | ------------------------+--------------------------------------------------- Comment(by jeffjensen): After working with this some more, I think the root cause is two processes concurrently logging to same file; in my case, running Infinitest, which runs tests in the background. The problem does not occur when I disable Infinitest (I worked a few hours with it disabled and the problem never occurred). If it is enabled and I manually run a test at the same time Infinitest is running tests, I can reproduce this problem consistently after about 3-4 runs. To have Infinitest enabled and use Lilith, I have to wait for Infinitest to complete running before manually launching any tests (need to manually run sometimes when only wanting to see results of one test or Infinitest didn't run test I'm interested in). Concurrent logging like this is probably not a supported configuration (the file is removed so reading the next is OutOfBounds), so I understand if you just close this one (perhaps a compromise is to handle the exception by reading from beginning of file?). If you want me to report any additional info, just let me know. It should be pretty easy for you to reproduce as well if you have further interest. A big thanks again for your responsiveness and making a great log viewer product. Regarding exceptions: There are 22 of these logged: java.lang.IndexOutOfBoundsException Invalid length (1792294932) at offset: 5468! at de.huxhorn.sulky.codec.filebuffer.DefaultDataStrategy.internalReadElement(DefaultDataStrategy.java:169) ~[de.huxhorn.sulky.codec.filebuffer-0.9.14.jar:na] at de.huxhorn.sulky.codec.filebuffer.DefaultDataStrategy.get(DefaultDataStrategy.java:130) ~[de.huxhorn.sulky.codec.filebuffer-0.9.14.jar:na] at de.huxhorn.sulky.codec.filebuffer.CodecFileBuffer.get(CodecFileBuffer.java:447) ~[de.huxhorn.sulky.codec.filebuffer-0.9.14.jar:na] at de.huxhorn.sulky.buffers.SoftReferenceCachingBuffer.get(SoftReferenceCachingBuffer.java:104) [de.huxhorn.sulky.buffers-0.9.14.jar:na] at de.huxhorn.sulky.buffers.table.BufferTableModel.getValueAt(BufferTableModel.java:182) [de.huxhorn.sulky.buffers.table-0.9.14.jar:na] at de.huxhorn.sulky.buffers.table.BufferTableModel.getValueAt(BufferTableModel.java:198) [de.huxhorn.sulky.buffers.table-0.9.14.jar:na] at javax.swing.JTable.getValueAt(JTable.java:2686) [na:1.6.0_24] at javax.swing.JTable.prepareRenderer(JTable.java:5703) [na:1.6.0_24] at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:2072) [na:1.6.0_24] at javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1974) [na:1.6.0_24] at javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:1770) [na:1.6.0_24] at javax.swing.plaf.ComponentUI.update(ComponentUI.java:143) [na:1.6.0_24] at javax.swing.JComponent.paintComponent(JComponent.java:752) [na:1.6.0_24] at javax.swing.JComponent.paint(JComponent.java:1029) [na:1.6.0_24] at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124) [na:1.6.0_24] at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1479) [na:1.6.0_24] at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1410) [na:1.6.0_24] at javax.swing.RepaintManager.paint(RepaintManager.java:1224) [na:1.6.0_24] at javax.swing.JComponent._paintImmediately(JComponent.java:5072) [na:1.6.0_24] at javax.swing.JComponent.paintImmediately(JComponent.java:4882) [na:1.6.0_24] at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:785) [na:1.6.0_24] at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713) [na:1.6.0_24] at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:693) [na:1.6.0_24] at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:125) [na:1.6.0_24] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) [na:1.6.0_24] at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:642) [na:1.6.0_24] at java.awt.EventQueue.access$000(EventQueue.java:85) [na:1.6.0_24] at java.awt.EventQueue$1.run(EventQueue.java:603) [na:1.6.0_24] at java.awt.EventQueue$1.run(EventQueue.java:601) [na:1.6.0_24] at java.security.AccessController.doPrivileged(Native Method)(AccessController.java) [na:1.6.0_24] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) [na:1.6.0_24] at java.awt.EventQueue.dispatchEvent(EventQueue.java:612) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) [na:1.6.0_24] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) [na:1.6.0_24] Followed by one of these: java.util.concurrent.ExecutionException java.io.IOException: Negative seek offset at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) ~[na:1.6.0_24] at java.util.concurrent.FutureTask.get(FutureTask.java:83) ~[na:1.6.0_24] at de.huxhorn.sulky.tasks.TaskManager$ResultListenerFireRunnable.run(TaskManager.java:593) ~[de.huxhorn.sulky.tasks-0.9.14.jar:na] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) [na:1.6.0_24] at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:642) [na:1.6.0_24] at java.awt.EventQueue.access$000(EventQueue.java:85) [na:1.6.0_24] at java.awt.EventQueue$1.run(EventQueue.java:603) [na:1.6.0_24] at java.awt.EventQueue$1.run(EventQueue.java:601) [na:1.6.0_24] at java.security.AccessController.doPrivileged(Native Method)(AccessController.java) [na:1.6.0_24] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) [na:1.6.0_24] at java.awt.EventQueue.dispatchEvent(EventQueue.java:612) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) [na:1.6.0_24] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) [na:1.6.0_24] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) [na:1.6.0_24]Caused by: java.io.IOException Negative seek offset at java.io.RandomAccessFile.seek(Native Method)(RandomAccessFile.java) ~[na:1.6.0_24] at de.huxhorn.lilith.swing.callables.IndexingCallable.call(IndexingCallable.java:141) ~[lilith.jar:na] at de.huxhorn.lilith.swing.callables.CheckFileChangeCallable.call(CheckFileChangeCallable.java:58) ~[lilith.jar:na] at de.huxhorn.lilith.swing.callables.CheckFileChangeCallable.call(CheckFileChangeCallable.java:27) ~[lilith.jar:na] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[na:1.6.0_24] at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[na:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_24] at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_24] -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/97#comment:3> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |
From: lilith - T. i. <no...@so...> - 2011-05-28 09:01:01
|
#97: After many runs that replace opened log file, Updating task fails with "Negative seek offset" ------------------------+--------------------------------------------------- Reporter: jeffjensen | Owner: huxhorn Type: defect | Status: assigned Priority: major | Milestone: unclassified Component: lilith-app | Version: 0.9.41 Keywords: | ------------------------+--------------------------------------------------- Changes (by huxhorn): * status: new => assigned Comment: Is there a stacktrace available? -- Ticket URL: <http://sourceforge.net/apps/trac/lilith/ticket/97#comment:2> lilith <http://sourceforge.net/projects/lilith/> Lilith - the Logback Logging- and Access-Event-Viewer. |