SLF4J / Logback is a fine system for logging, including reduced log line
work done when not logging (instead of the normal filtering system), and
also features an optional asynchronous appender. Even without it, it can
perfectly handle the load when configured correctly.
However, when run
Colin, be aware that running through service wrappers can introduce a lot
of overhead / blocking on logging due to stdout redirects.
Our application had to switch to SLF4J / Logback, since logging with JUL,
Log4J or to console / stdout and incorrectly configuring the wrapper could
lead to 100
On Wednesday, July 8, 2015 at 5:41:47 AM UTC-4, Niels van Klaveren wrote:
Colin, be aware that running through service wrappers can introduce a lot
of overhead / blocking on logging due to stdout redirects.
Our application had to switch to SLF4J / Logback, since logging with JUL,
Log4J or
Hi Alan,
Interesting point about the memory, they are defaults everywhere though. I am
going to deploy on Windows 7 as a service rather than running java -jar in a
command window; it does produce a bunch of debugging and maybe Windows 7
console compared to Windows XP console (for example) is
Maybe the JDK default memory/heap settings are different on Windows 7. What is
the memory pressure like on your Windows 7 system?
You might need to give your app more memory or at least a larger initial heap
allocation.
Does the app perform ok once it is up and running?
Alan
--
You received
Hi Colin,
I thought you might check:
* java -version to see if you're defaulting to client or server mode, and
maybe use -server to force that if it comes up client
* java -d64 to force 64-bit mode in case you have 32bit and 64bit JVM's
there
This is assuming you're on a 64-bit Windows and
Hi Nicolas, I don’t unfortunately (and I appreciate just how necessary focused
demos are). It isn’t a blocker so I don’t have the time to investigate this
much at the moment (major deadline approaching).
It is interesting that not many other people seem to be affected, and it is the
kind of
Hi Colin,
Would you have a subset of your app as a project on github/bitbucket so we
can help finding out ?
I am not sure it is related but the call to fsync in clojure
http://dev.clojure.org/jira/browse/CLJ-703
looks slightly similar to what other people are seeing.
Thanks both. I haven’t got that far (as it isn’t blocking me at this point) but
task manager shows Java at 100% (of a core) on Windows 7 where as it is much
much less on the other OSes. I think,as you say, the next step is profiling.
On 3 Jul 2015, at 21:50, Timothy Baldridge
Thanks Shantanu, good old AOP to the rescue.
On 4 Jul 2015, at 06:31, Shantanu Kumar kumar.shant...@gmail.com wrote:
Hi Colin,
If you know that the delay is happening in the server-side Clojure code,
maybe you can give https://github.com/kumarshantanu/espejito a try to
determine where
Hi all,
I have a Clojure/ClojureScript app using http-kit. When deployed on Windows
7 it is a insanely slow. For example, loading the first screen loads
immediately but then takes minutes to populate. The exact same jar on
Windows XP, OS X, Linux, Windows 2008 server etc. take a handful of
Hi Colin,
If you know that the delay is happening in the server-side Clojure code,
maybe you can give https://github.com/kumarshantanu/espejito a try to
determine where in the call stack is the latency happening?
Shantanu
On Friday, 3 July 2015 22:20:23 UTC+5:30, Colin Yates wrote:
Hi all,
Take thread dumps with ctrl-break and see what it's doing? Could be something
with the filesystem?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are
Yourkit has free trials, give it a try.
Timothy
On Fri, Jul 3, 2015 at 2:23 PM, Alex Miller a...@puredanger.com wrote:
Take thread dumps with ctrl-break and see what it's doing? Could be
something with the filesystem?
--
You received this message because you are subscribed to the Google
14 matches
Mail list logo
