I was naive enough to think that this issue would have been fixed in
ZoneAlarm by now, so I tried to upgrade again. Similar problems...
BUT this time I notice something even stranger!
Only one of my webapps is affected. Serving a static .html from one
webapp (or resin-doc / resin-admin pages)
On Oct 6, 2007, at 4:03 AM, Mattias Jiderhamn wrote:
Also, what is the stack trace for the slow read() call?
With JNI, 57% of the time for loading a single page (total 78 s) is
spent in
com.caucho.vfs.JniStream.read cased by (only!!!) 22 calls from
com.caucho.vfs.ReadStream.readBuffer
On Oct 6, 2007, at 12:03 PM, Chris Chen wrote:
Rather than doing all the profiling like you (which I would have
liked to but i was too lazy), I just did a thread dump. It appeared
to be occurring within the VFS package. Resin 3.1.2 under Linux
CentOS 4.x was spending FOREVER inside the
On Oct 6, 2007, at 12:03 PM, Chris Chen wrote:
Rather than doing all the profiling like you (which I would have
liked to but i was too lazy), I just did a thread dump.
By the way, the Resin admin now has a quick-and-dirty profiler (and
thread dumper and heap dumper) which is really handy
Yea,
This is a good way. Unfortunately, I believe resin-admin uses
Quercus. I have disabled Quercus because I have php apps running
that are not running properly under it. When I enable php
processing, Resin takes control over ALL files with the php
extension, which shouldn't be the
I have tried turning other applications and services, including firewall
and anti-virus, off.
Disk operations outside Resin (such as zipping the project or
defragmenting the disc) does not seem affected.
Thanks for the guess though.
/Mattias
Andre van Dalen wrote:
Wild guess; maybe your
Wild guess; maybe your viruschecker decided to check those reads where
previously it did not
(possibly also unpacking .jars on the fly in-memory as it sees them as zip
archives) ?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Mattias Jiderhamn
Sent:
Serge Kystautas wrote:
I've seen something like this, and we were able to diagnose it on a Unix
environment by using a program called truss
(http://www.scit.wlv.ac.uk/cgi-bin/mansec?1+truss) which allows you to
watch every file that is getting read. I don't know of a Windows
equivalent.
I've seen small TCP/IP MTU sizes cause similar behavior. We had VPN
software that set the MTU to less than the IP default, which I think should
have been 1500(?). Result was packet fragmentation that caused huge delays
in the Microsoft TCP implementation. I think the MTU setting, in this case,
