-
1. Re: client log4j
genman May 4, 2005 8:41 PM (in response to thomas.heiss)
You're closing the connection (jmsConn) twice. -
2. Re: client log4j
mikezzz May 5, 2005 11:06 AM (in response to thomas.heiss)You're closing the connection (jmsConn) twice.
Actually he isn't. Firstly he's stopping the connection then at the end he closing it. This is practice shown in the JBoss JMS samples:package org.jboss.chap6.ex2; ... public void stop() throws JMSException { conn.stop(); session.close(); conn.close(); }
I have run into the same problem and it occurs only when the QueueSesssion is created as transactionalQueueSession qs = conn.createSession(true, 0);
It appears that closing the connection means that the underlying physical is closed before the messages associated to the transaction are written to the queue. Hence this exception occurs. This does not occur when transacted is to false.
I think this may be a bug.
Mike. -
3. Re: client log4j
adrian.brock May 5, 2005 11:48 AM (in response to thomas.heiss)You guys crack me up. Don't you have something better to do than look at none problems?
Which part about "DEBUG" don't you understand?
The correct way to handle a close is actually in the line of code you are complaining about:
ServerSocketManagerHandler:public void close() { try { if (closed == false) server.connectionClosing(connectionToken); } catch (Exception e) { // My Comment: Do we care? I think not. We can't do anything about it! log.debug("Error closing connection: ", e); } }
If it is a "bug" it is that it should really be logged at TRACE level rather than DEBUG. -
4. Re: client log4j
adrian.brock May 5, 2005 11:51 AM (in response to thomas.heiss)While we are on this, the example code is just plain wrong and redundant.
1) A connection.close() does connection.stop() and session.close()/etc.
automatically. Read the JMS spec.
2) The example code fails to cleanup the connection properly in the event of errors:try { if (jmsConn != null) jmsConn.stop(); // My Comment: A JMS exception here or any other line before the close bypasses jmsConn.close() !!!!!! if (jmsPub != null) jmsPub.close(); if (jmsSession != null) jmsSession.close(); if (jmsConn != null) jmsConn.close(); } catch (JMSException ex) { System.out.println("JMSEventHandlerThread: JMSException in jmsCleanup: " + ex.getMessage()); }
-
5. Re: client log4j
adrian.brock May 5, 2005 11:57 AM (in response to thomas.heiss)Link to ask for the bad example in the docs to be fixed:
http://jira.jboss.com/jira/browse/JBDOCS-84 -
6. Re: client log4j
minmay May 5, 2005 8:16 PM (in response to thomas.heiss)I've read through the list a few times, and I STILL don't know
how to solve this problem. Okay, the documentation is wrong.
Then how is the connection closed? I followed your directions.
I didn't modify JBoss JMS examples, I am simply running them.
But running them throws IEO exception.
Then I did a modification of the code, as suggested in this post:
now there is no conn.stop() or session.close();
I only have a conn.close();
BUT THAT STILL does not stop the IEO exception.
Here is a partial trace output:
[org.jboss.mq.il.uil2.ServerSocketManagerHandler] Setting up the UILClientIL Connection
2005-05-05 16:57:50,344 DEBUG [org.jboss.mq.il.uil2.ServerSocketManagerHandler] The UILClientIL Connection is set up
2005-05-05 16:57:50,654 DEBUG [org.jboss.mq.il.uil2.ServerSocketManagerHandler] Exiting on IOE
java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:162)
I beg you Adriane, since you're the one who seems to know the answer to this, to post a solution. -
7. Re: client log4j
genman May 5, 2005 10:06 PM (in response to thomas.heiss)
Sorry Adrian, I didn't see that the exception was logged with a DEBUG.
I guess people think that exceptions logged as DEBUG count as bugs in JBoss. Basically, they should be IGNORED.
I now know better than to log exceptions using DEBUG at work because it confuses and alarms people. -
8. Re: client log4j
mikezzz May 6, 2005 5:15 AM (in response to thomas.heiss)It's entirely possible that the Exception message is a red hearing however I neglected to mention that when using a transacted session the message never arrives on the Queue (the exception is the only relevant message in the log to indicate that the publishing failed). It works fine when using a non-transactional session. My pusblishing class is:
public void send(Serializable payload) throws NamingException, JMSException { QueueConnectionFactory fact = null; QueueConnection cn = null; Queue q = null; InitialContext ic = new InitialContext(); fact = (QueueConnectionFactory) ic.lookup("ConnectionFactory"); q = (Queue) ic.lookup(getJndiName()); try { cn = fact.createQueueConnection(); QueueSession sess = cn.createQueueSession(true, 0); cn.start(); QueueSender qs = sess.createSender(q); Message message = sess.createObjectMessage(payload); qs.send(message); } finally { if (cn != null) { try { cn.close(); } catch (Throwable t) { System.out.println(t.getMessage()); } } } }
I'm fairly certain that code above is correct for sending a message transactionally. Its called from within a Stateless Session Bean method with a transaction type of Required. If no one can point out anything functionally wrong with the above I will raise a jira case for this. I have an isolated test case that will replicate the problem.
Mike. -
9. Re: client log4j
mikezzz May 6, 2005 5:37 AM (in response to thomas.heiss)Sorry, ignore me I'm talking crap ic.lookup("java:/JmsXA").
<Slaps himself>.
Cheers,
Mike. -
10. Re: client log4j
thomas.heiss May 6, 2005 1:06 PM (in response to thomas.heiss)Sorry Adrian, didn't want to get you angry.
I am a Jboss newbie and I don't know too much in detail about Jboss debugging and problems/or not.
As to my try{...} catch(...) {} block.
You are of course completely right.
It is totally wrong.
I should have used better
try{
}
catch () {
}
finally{
jmsPub.close();
jmsConn.close();
}
Now that you say it, it got back into my mind :)
Thanks for feedback.
Thomas -
11. Unnecessary exceptions while shutting down jboss jms server
irfan1078 May 20, 2005 6:59 AM (in response to thomas.heiss)I am trying to build a common JMS Logger. As a fail over, in case the Jboss JMS server is shut down the client application should revert back to log the corressponding log in a file. I have used my own ExceptionListener. But as soon as when I shutdown Jboss server the log is written down in a file but I also get the Exception's the which irritates me.
org.jboss.util.NestedThrowable.parentTraceEnabled=true--2005-05-20 15:37:23,736
org.jboss.util.NestedThrowable.nestedTraceEnabled=false--2005-05-20 15:37:23,736
org.jboss.util.NestedThrowable.detectDuplicateNesting=true--2005-05-20 15:37:23,
736
IN MyExceptionListener
Stopping--2005-05-20 15:37:23,736
End ReadTask.run--2005-05-20 15:37:23,736
End WriteTask.run--2005-05-20 15:37:23,736
I want this to be removed from logs, as I am catching all the required exceptions, I hope.
The following is the code for jms logger
package com.kotak.logger;
/**
*
*
*
*
* @author Irfan Bagalkote
* @version $Creation: 1.0 $
*/
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.jms.QueueConnectionFactory;
import javax.jms.QueueConnection;
import javax.jms.QueueSession;
import javax.jms.QueueSender;
import javax.jms.Queue;
import javax.jms.TextMessage;
import javax.jms.Session;
import javax.jms.JMSException;
import java.util.Hashtable;
public class JMSLogger implements ApplicationLogger {
Context context = null;
QueueConnectionFactory queueFactory = null;
QueueConnection queueConnection = null;
QueueSession queueSession = null;
QueueSender queueSender = null;
Queue queue = null;
public synchronized boolean destination(){
try{
Hashtable props = new Hashtable();
props.put(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
props.put(Context.PROVIDER_URL, "localhost:1099");
props.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
// Get initial context with given properties
Context context = new InitialContext(props);
// Get the connection factory
QueueConnectionFactory queueFactory = (QueueConnectionFactory)context.lookup("ConnectionFactory");
// Create the connection
queueConnection = queueFactory.createQueueConnection();
queueConnection.setExceptionListener(new MyExceptionListener());
// Create the session
queueSession = queueConnection.createQueueSession(
// No transaction
false,
// Auto ack
Session.AUTO_ACKNOWLEDGE);
System.out.println("8");
// Look up the destination
queue = (Queue)context.lookup("queue/QueueName");
// Create a sender
queueSender = queueSession.createSender(queue);
return true;
}catch(NamingException e){
return false;
}catch(JMSException e){
return false;
}catch(Exception e){
return false;
}
}
public void log(String logMsg) throws Exception{
this.send(logMsg);
}
/**
* Send the given String as a JMS message to the testQueue queue.
*/
public void send(String msg) throws JMSException {
// Create a message
TextMessage message = queueSession.createTextMessage();
message.setText(msg);
// Send the message
queueSender.send(queue, message);
}
class MyExceptionListener implements javax.jms.ExceptionListener{
public void onException(JMSException jmse2){
try{
System.out.println("IN MyExceptionListener");
queueConnection.close();
// Do something: e.g. try to reconnect to the server
// if it has the connection is lost
}catch(Exception e){}
}
}
} -
12. Re: client log4j
irfan1078 May 21, 2005 5:32 AM (in response to thomas.heiss)I am sorry folks about the earlier post. The problem was cause I didnt knew the working of jboss very well, I suppose, I may be wrong again. If someone with good knowledge can confirm it that will be good. I know the solution now for the post I have made.
Jboss Jms works on the ping pong concept that took a bit long time for me to find out how exactly it worked. I knew there was a thread running behind which carried out the ping pong thing.
If you see my code, I will stick and paste the part of the code where I identified the bug
/**
* Send the given String as a JMS message to the testQueue queue.
*/
public void send(String msg) throws JMSException {
// Create a message
TextMessage message = queueSession.createTextMessage();
message.setText(msg);
// Send the message
queueSender.send(queue, message);
}
If you see in above code I was forwarding the Jms exception thrown as it is, by the time the other part of program where it could catch the the exception and do something needful, the separate ping pong thread which was running used to throw its own exception. and I was getting the un-needed exception in my output log so when I changed the code as follows, the error was finally resolved after 2 days for me hope i save someone elses time.
/**
* Send the given String as a JMS message to the testQueue queue.
*/
public void send(String msg) throws Exception {
try{
// Create a message
TextMessage message = queueSession.createTextMessage();
message.setText(msg);
// Send the message
queueSender.send(queue, message);
}catch(JMSException jmse){
try{
if (queueConnection != null)
queueConnection.close();
//throw my own exception other than JMSException
throw new NullPointerException();
}catch(JMSException jmse){
//for connection exception
}
}
}
what I am doing in my above i am catching the exception thrown at that very moment at close the connection so the ping pong thread will stop functioning and later I throw my own exception as I want a centralised place for exception handling and wish to do something with that exception in my other part of program..
Hope the query is resolved. If someone can check it it will be good
Thanks in adavance
Irfan Bagalkote -
13. Re: client log4j
ensonik Sep 8, 2005 4:03 PM (in response to thomas.heiss)You guys crack me up. Don't you have something better to do than look at none problems? Which part about "DEBUG" don't you understand?
I have to say, I'm not easily shocked, but when I saw your email address and the way you replied, it made Hani seem a bit more right about you guys. -
14. Re: client log4j
glyn_walters Aug 2, 2006 11:48 AM (in response to thomas.heiss)"Ensonik" wrote:
You guys crack me up. Don't you have something better to do than look at none problems? Which part about "DEBUG" don't you understand?
I have to say, I'm not easily shocked, but when I saw your email address and the way you replied, it made Hani seem a bit more right about you guys.
Yup a strange thread. Rudeness from the JBoss representative. And a poor and rambling explanation from him about the issue. Plus a lack of understanding that their pointless "DEBUG" spam is a problem in a situation where you need debug level on.