client log4j "java.net.SocketException: socket closed" and s

[thomas.heiss]

Hello JBoss experts,

as it seems my JMS is running (subscriber and publisher).

But in my log4 Java client app with log4j.properties from your FAQ I receive some exceptions. Also an exception occurs in Jboss 4.01sp1 server.log (running on Windows 2000).

Java client application (jbossmq.log):
2005-05-04 09:17:22,984 DEBUG [org.jboss.mq.il.uil2.ServerSocketManagerHandler] Exiting on IOE
java.io.EOFException

According to the log my app is closing the session and connections.
Is it normal, that this EOFException occurs then? Maybe it is normal in DEBUG mode? I am not sure.

This is my jmsCleanup() method:
try {

if (jmsConn != null) jmsConn.stop();
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());
}

Would be new to me that close() of session also closes TopicConnection?

And this occurs on JBoss side:
java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.readByte(ObjectInputStream.java:2603)
at java.io.ObjectInputStream.readByte(ObjectInputStream.java:845)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:285)
at java.lang.Thread.run(Thread.java:534)

I also expect that it should be not normal to receive this exception in the server.log?

Regards
Thomas

[genman]

You're closing the connection (jmsConn) twice.

[mikezzz]

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 transactional

QueueSession 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.

[adrian.brock]

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.

[adrian.brock]

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());
}

[adrian.brock]

Link to ask for the bad example in the docs to be fixed:
http://jira.jboss.com/jira/browse/JBDOCS-84

[minmay]

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.

[genman]

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.

[mikezzz]

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.

[mikezzz]

Sorry, ignore me I'm talking crap ic.lookup("java:/JmsXA").

<Slaps himself>.

Cheers,
Mike.

[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

[irfan1078]

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){}

}
}

}

[irfan1078]

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

[ensonik]

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.

[glyn_walters]

"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.