I'm not sure we're talking about the same thing here. The thread dump
you are referring to looks more like a stack trace to me. A thread dump
contains a stack trace for all threads currently running in the JVM and
it also lists the locks a thread has acquired and whether it is waiting
for a particular lock to become available. This is extremely useful when
resolving deadlocks and such (which could be the problem here).
Anyways, when you have your thread dump here's how you create an issue
in JIRA:
Go to https://issues.apache.org/jira/secure/Dashboard.jspa and register.
Once you've registered and logged in go to
https://issues.apache.org/jira/secure/CreateIssue!default.jspa and
create the new issue. Attach your thread dump to the issue.
HTH
/Niklas
[EMAIL PROTECTED] wrote:
Oh, that was not the problem. Creating the JIRA was the problem :)
I just didn't think that the thread dump was important, since it doesn't
contain much information.
Thread[SocketIoProcessor]
Object.wait(long) line: not available [native method]
SocketSession(Object).wait() line: 474
SocketSession.close(boolean) line: 137
DatastructureProtocolHandler.exceptionCaught(IoSession, Throwable)
line: 438
As I said, the calling thread gets blocked in the wait.
-----Original Message-----
From: Niklas Therning [mailto:[EMAIL PROTECTED]
Sent: 30 August 2006 16:07
To: [email protected]
Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2
To get a thread dump on Windows hit Ctrl+Break in the console window
running your application. The thread dump will be written on
the console.
To get a thread dump on Linux/Unix hit Ctrl+\ in the console
window or
send the QUIT signal to the process like this:
kill -3 <pid>
where <pid> is the id of your Java process. The thread dump will be
written to the console (or wherever you've directed stdout).
HTH
/Niklas
[EMAIL PROTECTED] wrote:
Hi,
I don't know how to do that, and I don't know what to add
except for the
information which I already have posted.
This worked as a workaround:
public void exceptionCaught(final IoSession session, Throwable
e) throws Exception {
String logString = "Caught exception on session: " +
session + " ";
if (session instanceof BaseSession) {
logString += " remote: " +
((BaseSession)session).getRemoteAddress() + " ";
}
LOGGER.warn("exceptionCaught", logString +
e.getMessage());
//XXX: Workaround for bug(?) in MINA 0.8.2.
//session closed can't be invoked by calling thread.
Could be
//changed so that it uses a thread pool
new Thread() {
public void run() {
//This call will block calling thread so
no one can do
//notify if we don't spawn a new thread
session.close(true);
}
}.start();
}
-----Original Message-----
From: Trustin Lee [mailto:[EMAIL PROTECTED]
Sent: 22 August 2006 06:56
To: [email protected]
Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2
Could you please open a JIRA issue which attaches your full
thread dump?
Thanks in advance,
Trustin
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi,
I have some problems during upgrade from 0.7.3 to 0.8.2. I
think I can
write a work around for the problem, but I'm not sure how
things are
supposed to be.
The scenario is that a client connection which implements
IoHandler has
a connection towards the server. The session on the
connection should be
removed if the connection is terminated, and I should
also inform my
upper layers about the disconnect.
This is how the flow was in 0.7.3 when a disconnect was
detected (Remote
end is abruptly disconnecting):
exceptionCaught -> session.close(true) -> sessionClosed
That is I call session.close(true) from the method
exceptionCaught, and
that leads to a callback to sessionClosed. I do some cleanup in
sessionClosed and informs my upper layers about the disconnect.
This happens in 0.8.2:
exceptionCaught -> session.close(true) -> blocked in wait.
That is, the thread hangs / is blocked in wait, and never
gets out of
it.
The problem does not occur if session.close(true) is called
on client
side during normal program flow.
Is this how it's supposed to work?
Thanks for your help
Kaj
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
