[Bug 57267] Document /save command in ManagerServlet and StoreConfig feature
https://issues.apache.org/bugzilla/show_bug.cgi?id=57267 Oleg Trokhov changed: What|Removed |Added OS||All --- Comment #1 from Oleg Trokhov --- Sorry if it naive question, but i have error "FAIL - Encountered exception javax.management.InstanceNotFoundException: Catalina:type=StoreConfig" when call command "/save". When I debug, I found that programm cant pass StandartServer.storeContext() method. What can you advise me? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57265] Tomcat 8 hiden behind NGINX fails to send file when using NIO connector
https://issues.apache.org/bugzilla/show_bug.cgi?id=57265 --- Comment #1 from Mark Thomas --- Just to confirm my reading of the stacktrace, you are using Sendfile with SSL, right? Is that is the case, are you sure using Sendfile is providing any benefit? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57281] Tomcat fails to call method of non-public filter class configured via Servlet 3.0 API when running with SecurityManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=57281 --- Comment #1 from Mark Thomas --- Trivial test case to reproduce: https://github.com/markt-asf/tomcat-bug57281 I'm moving on to testing the proposed fix. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57281] Tomcat fails to call method of non-public filter class configured via Servlet 3.0 API when running with SecurityManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=57281 --- Comment #2 from Mark Thomas --- I can confirm that the proposed fix works. I'll commit it once the svn server comes back to life. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57282] request process UML diagram seems outdated
https://issues.apache.org/bugzilla/show_bug.cgi?id=57282 Mark Thomas changed: What|Removed |Added OS||All --- Comment #3 from Mark Thomas --- Yes, those diagrams are out of date. The problem is bigger than you have identified. Page 2 is completely wrong. The call sequence is very different. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56966] AccessLogValve's elapsed time has 15ms precision on Windows
https://issues.apache.org/bugzilla/show_bug.cgi?id=56966 --- Comment #5 from Christopher Schultz --- (In reply to Konstantin Kolinko from comment #1) > I see 1ms precision when running on Windows 7. I see 1ms running on Linux. > The last time when I observed 10ms was Windows XP, but Windows XP is now > End-of-life. +1 I don't have any non-virtual Windows instances available for testing, unfortunately. I don't trust real-time clocks on VMs. > Note that System.nanoTime() has caveats. It makes sense only when measuring > time intervals. It cannot be used to measure current time. > > req.getStartTime() is used as wall clock time value. It means that there has > to be another field in addition to req.getStartTime(). It also means that > there needs to be a change to the Log interface to pass a nano time value in > addition to milli time one. AccessLogValve could take its own timestamps in nanos, though the start time would be "after" req.getStartTime(). Or we could use (nanos / 1000) to get "better" resolution for the time-interval for a request. It seems like extra work for little benefit. (Though those experiencing 15ms-minimums would certainly argue that the benefit is great.) > Is there much interest in measuring times shorter than 1ms? Usually there is > an interest in requests that take a long time. +1 For resources that run reasonably faster than 15ms, one can use a Filter around them to collect metrics and aggregate total time over many requests to get a mean-request-time if that's what you ultimately want. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57282] request process UML diagram seems outdated
https://issues.apache.org/bugzilla/show_bug.cgi?id=57282 --- Comment #4 from Stephen Chen --- (In reply to Mark Thomas from comment #3) > Yes, those diagrams are out of date. > > The problem is bigger than you have identified. Page 2 is completely wrong. > The call sequence is very different. Hi Mark, community would fix that in the future? or what can I help ? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
