Sorry, got pulled into a support task early this AM.
Ummmm.... That didn't work out so well
Downloaded jip-1.1.1.zip & unzzipped it into ~/jip
Modified wrapper.conf to add:
# Added for MINA JIP profiling
wrapper.java.additional.4=-javaagent:~/jip/profile/profile.jar
wrapper.java.additional.5=-Dprofile.properties=~/jip/profile/profile-mina.properties
Created ~/jip/profile/profile-mina.properties to contain a copy of the
settings you gave, and launched our application.
Actually, launched wrapper.... our application never got launched,
because of:
STATUS | wrapper | 2009/05/01 10:58:20 | Launching a JVM...
ERROR | wrapper | 2009/05/01 10:58:20 | JVM exited while loading the
application.
INFO | jvm 4 | 2009/05/01 10:58:20 | Error opening zip file:
~/jip/profile/profile.jar
INFO | jvm 4 | 2009/05/01 10:58:20 | Error occurred during
initialization of VM
INFO | jvm 4 | 2009/05/01 10:58:20 | agent library failed to
init: instrument
I'm gonna *assume* I got a bad download, start over and try again. :-)
boB
Emmanuel Lecharny wrote:
boB Gage wrote:
You're making me think ... :-) and that's a good thing.
I would have kept the same handler, just switched the codec.
Creating a new NioConnector is quite expensive.
Hmmm, the (someone else's) code I started from doesn't lend itself
well to that... The handler, codec factory, encoders, and decoders
are all tightly linked functionally with a single discoverable device
family (protocol). And it's working fairly well... ( at least
with 2.0.0-M4 ) except for the unbound thread growth on the discovery
failures. If I run a test with twice our normal expected number of
devices attached and discoverable, everything runs through a few
discovery cycles and eventually each lands on the right port and
everyone's fat & happy for days. There's some number of threads
stuck in WAIT states, but it's been a relatively constant number
since the last device was discovered. [ IOW, the problem hides well ]
Ok, let put aside the architecture change... I guess you have no time
nor need to do that. Let's address the real problem !
So you have a thread stuck in a session.write() : seems like the other
side is not responding. Can you do something ? There is a small but
smart tool dumping all the methods calls into a text file. It's not
intrusive, you just have to add some parameters into your VM command
line :
-javaagent:~/jip/profile/profile.jar
-Dprofile.properties=~/jip/profile/profile-mina.properties
JIP is a small profiler, you can download it at
http://jiprof.sourceforge.net/
Here is the properties I have set for mina :
profiler=on
remote=off
port=15599
ClassLoaderFilter.1=com.mentorgen.tools.profile.instrument.clfilter.StandardClassLoaderFilter
thread-depth=-1
thread.compact.threshold.ms=1
max-method-count=-1
method.compact.threshold.ms=1
file=~/profile-mina.txt
exclude=org.eclipse,org.junit,org.slf4j,org.apache.log4j,org.apache.commons,org.bouncycastle
track.object.alloc=on
output=text
output-method-signatures=yes
clock-resolution=ns
The most important line is the 'exclude' one : it removes all the
methods from a specific package.
Give it a try, and attach the resulting file (after a single run) in a
JIRA (it might be stripped out by the mailer).
--
boB Gage
Software Engineer
Merge Healthcare
This message is a PRIVATE communication. This message and all
attachments are a private communication and may be confidential or
protected by privilege. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
information contained in or attached to this message is strictly
prohibited. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
