RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Looks good Hiram,
Can I make one suggestion. When I was profiling and improving JBossMQ's
performance I implemented a couple of static methods
SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the
standard writeObject and readObject methods. I think you should use them
here.
They work fine, you get back exactly the same object you write out, and they
are used by all the persistence and communication mechanisms currently
because they are many times quicker than the standard object serialization
(which is horribly slow).
Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system. Several of these have been
introduced with the advent of the message caching and David J's new stuff.
The cost of constructing all the message strings, even if they aren't used,
can add considerable overhead to the system (if you don't believe me then
create a test and see). Remember I managed to get somewhere between a 10 to
20 times speed improvement by improving the serialisation code and removing
these debug statements from inside the inner loop. If you really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag set to false the
compiler removes the line completely, so there is no performance hit at all.
Thanks David.
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 5:24 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
CacheStore.java CacheStoreMBean.java
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store.
This should lay the
ground work needed so that the MessageCache can use a PM
for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly
restoring the message
after a server restart.
Revision ChangesPath
1.1
jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
Index: CacheStore.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm.file;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
import org.jboss.system.ServiceMBeanSupport;
/**
* This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino
* @version$Revision: 1.1 $
*/
public class CacheStore extends ServiceMBeanSupport
implements org.jboss.mq.pm.CacheStore, CacheStoreMBean {
String dataDirectory;
File dataFile;
/**
* @see ServiceMBeanSupport#getName()
*/
public String getName() {
return JBossMQ-CacheStore;
}
/**
* @see CacheStore#loadFromStorage(MessageReference)
*/
public SpyMessage loadFromStorage(MessageReference mh)
throws JMSException {
try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectInputStream is = new ObjectInputStream(new
BufferedInputStream(new FileInputStream(f)));
Object rc = is.readObject();
is.close();
return (SpyMessage) rc;
} catch (ClassNotFoundException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
} catch (IOException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
}
}
/**
* @see CacheStore#saveToStorage(MessageReference, SpyMessage)
*/
public void saveToStorage(MessageReference mh,
SpyMessage message) throws JMSException {
try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectOutputStream os = new ObjectOutputStream(new
BufferedOutputStream(new FileOutputStream(f)));
os.writeObject(message);
os.close();
} catch (IOException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
}
}
/**
* @see
Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace level message
that is enclosed inside of a test for that priority level being active. This
allows for enabling tracing with very fine control at runtime and one of
the primary reasons for basing logging on log4j. This incurs a minimal
overhead. The current Logger class is a subclass of the log4j Category
and this will be changed next week, but that will not change the usage
pattern which is as follows:
import org.jboss.logging.Logger;
public abstract class SomeClass
{
protected Logger log = Logger.create(Some.class or whatever category
name);
protected void register(EntityEnterpriseContext ctx, Transaction tx)
{
boolean trace = log.isTraceEnabled();
if( trace )
log.trace(register, ctx=+ctx+, tx=+tx);
}
}
The cost of constructing all the message strings, even if they aren't
used,
can add considerable overhead to the system (if you don't believe me then
create a test and see). Remember I managed to get somewhere between a 10
to
20 times speed improvement by improving the serialisation code and
removing
these debug statements from inside the inner loop. If you really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag set to false the
compiler removes the line completely, so there is no performance hit at
all.
Thanks David.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Thanks, that's good to know. The amount and level of logging in JBossMQ
needs to be looked at, its not completely hopeless, but its far from
consistent (mainly because of my changes I guess).
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 9:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update:
jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace
level message
that is enclosed inside of a test for that priority level
being active. This
allows for enabling tracing with very fine control at runtime
and one of
the primary reasons for basing logging on log4j. This incurs a minimal
overhead. The current Logger class is a subclass of the log4j Category
and this will be changed next week, but that will not change the usage
pattern which is as follows:
import org.jboss.logging.Logger;
public abstract class SomeClass
{
protected Logger log = Logger.create(Some.class or
whatever category
name);
protected void register(EntityEnterpriseContext ctx,
Transaction tx)
{
boolean trace = log.isTraceEnabled();
if( trace )
log.trace(register, ctx=+ctx+, tx=+tx);
}
}
The cost of constructing all the message strings, even if
they aren't
used,
can add considerable overhead to the system (if you don't
believe me then
create a test and see). Remember I managed to get
somewhere between a 10
to
20 times speed improvement by improving the serialisation code and
removing
these debug statements from inside the inner loop. If you
really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag
set to false the
compiler removes the line completely, so there is no
performance hit at
all.
Thanks David.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
On Thu, 15 Nov 2001, David Maplesden wrote: if(DEBUG) log.debug(a message); so that we can easily set the flag to false and recompile a higher performance version of the engine. With the static flag set to false the compiler removes the line completely, so there is no performance hit at all. I doubt this is fully true. I once did a decompile of a .class(a bad rm removed the .java), and it gave me mostly functioning code. However, I can't recall if there was any use of static finals. The compiler probably just has a goto that jumps over it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system. Several of these have been
introduced with the advent of the message caching and David J's new stuff.
The cost of constructing all the message strings, even if they aren't used,
can add considerable overhead to the system (if you don't believe me then
create a test and see). Remember I managed to get somewhere between a 10 to
20 times speed improvement by improving the serialisation code and removing
these debug statements from inside the inner loop. If you really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
Please don't do this. Use something more like this:
if (log.isDebugEnabled()) {
log.debug(some msg);
log.debug(some other msg);
}
If you are really trying to trim down execution costs and you have lots of
spread out debugs in a method, then something like this:
boolean debug = log.isDebugEnabled();
// ...
if (debug) {
log.debug(foo);
}
// ...
if (debug) {
log.debug(bar);
}
The cost of this is minor and allows for dynamic contol over the processing
of these log messages.
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
In general the logging in Main is way overboard as not everyone is upto
speed with the trace level logging support. This is the first thing I will
address when I get back to working on Main next week.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 12:52 PM
Subject: RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
CacheStore.java CacheStoreMBean.java
Thanks, that's good to know. The amount and level of logging in JBossMQ
needs to be looked at, its not completely hopeless, but its far from
consistent (mainly because of my changes I guess).
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 9:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update:
jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace
level message
that is enclosed inside of a test for that priority level
being active. This
allows for enabling tracing with very fine control at runtime
and one of
the primary reasons for basing logging on log4j. This incurs a minimal
overhead. The current Logger class is a subclass of the log4j Category
and this will be changed next week, but that will not change the usage
pattern which is as follows:
import org.jboss.logging.Logger;
public abstract class SomeClass
{
protected Logger log = Logger.create(Some.class or
whatever category
name);
protected void register(EntityEnterpriseContext ctx,
Transaction tx)
{
boolean trace = log.isTraceEnabled();
if( trace )
log.trace(register, ctx=+ctx+, tx=+tx);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
Oops, did you remove the excess debug statements I put in or can you point
a bit to where they might be? I'm not at all sure I could recognize such
places..
David Jencks
On 2001.11.14 14:56:29 -0500 David Maplesden wrote:
Looks good Hiram,
Can I make one suggestion. When I was profiling and improving JBossMQ's
performance I implemented a couple of static methods
SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of
the
standard writeObject and readObject methods. I think you should use them
here.
They work fine, you get back exactly the same object you write out, and
they
are used by all the persistence and communication mechanisms currently
because they are many times quicker than the standard object
serialization
(which is horribly slow).
Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system. Several of these have
been
introduced with the advent of the message caching and David J's new
stuff.
The cost of constructing all the message strings, even if they aren't
used,
can add considerable overhead to the system (if you don't believe me then
create a test and see). Remember I managed to get somewhere between a 10
to
20 times speed improvement by improving the serialisation code and
removing
these debug statements from inside the inner loop. If you really, really
want them then place them behind a static final boolean flag i.e.
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag set to false the
compiler removes the line completely, so there is no performance hit at
all.
Thanks David.
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 5:24 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file
CacheStore.java CacheStoreMBean.java
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store.
This should lay the
ground work needed so that the MessageCache can use a PM
for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly
restoring the message
after a server restart.
Revision ChangesPath
1.1
jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
Index: CacheStore.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm.file;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
import org.jboss.system.ServiceMBeanSupport;
/**
* This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino
* @version$Revision: 1.1 $
*/
public class CacheStore extends ServiceMBeanSupport
implements org.jboss.mq.pm.CacheStore, CacheStoreMBean {
String dataDirectory;
File dataFile;
/**
* @see ServiceMBeanSupport#getName()
*/
public String getName() {
return JBossMQ-CacheStore;
}
/**
* @see CacheStore#loadFromStorage(MessageReference)
*/
public SpyMessage loadFromStorage(MessageReference mh)
throws JMSException {
try {
File f = new File(dataFile, Message- + mh.referenceId);
ObjectInputStream is = new ObjectInputStream(new
BufferedInputStream(new FileInputStream(f)));
Object rc = is.readObject();
is.close();
return (SpyMessage) rc;
} catch (ClassNotFoundException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
} catch (IOException e) {
throw new SpyJMSException(Could not load message
from secondary storage: , e);
}
}
/**
* @see CacheStore#saveToStorage(MessageReference, SpyMessage)
*/
public void saveToStorage(MessageReference mh,
SpyMessage message) throws JMSException {
try {
File f = new File(dataFile, Message- +
RE: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
I haven't removed any debug statements since I did my initial big contribution some months ago, I thought people might be using them trying to track down a particular bug. Now that we are so close to 3.0 coming out I thought I would mention it in passing so people where aware of the performance hit they impose, of course all we need to do is change them from log.debug() to if(log.isTraceEnabled()) log.trace() and we should be fine. The critical parts of the code are the areas that get executed for every message under normal conditions, anything to do with the basic send, receive, commit methods + the corresponding areas of the various PM's and now the message cache. I don't think many of the changes you have made recently have really been in these areas so you are probably fine. One off things like the restore method and initialisation stuff we can log as much as we like. David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 10:30 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java Oops, did you remove the excess debug statements I put in or can you point a bit to where they might be? I'm not at all sure I could recognize such places.. David Jencks On 2001.11.14 14:56:29 -0500 David Maplesden wrote: Looks good Hiram, Can I make one suggestion. When I was profiling and improving JBossMQ's performance I implemented a couple of static methods SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the standard writeObject and readObject methods. I think you should use them here. They work fine, you get back exactly the same object you write out, and they are used by all the persistence and communication mechanisms currently because they are many times quicker than the standard object serialization (which is horribly slow). Oh, and if we are talking about performance, I would appreciate everyone being very careful about placing debug statements inside any code that is executed for every message through the system. Several of these have been introduced with the advent of the message caching and David J's new stuff. The cost of constructing all the message strings, even if they aren't used, can add considerable overhead to the system (if you don't believe me then create a test and see). Remember I managed to get somewhere between a 10 to 20 times speed improvement by improving the serialisation code and removing these debug statements from inside the inner loop. If you really, really want them then place them behind a static final boolean flag i.e. if(DEBUG) log.debug(a message); so that we can easily set the flag to false and recompile a higher performance version of the engine. With the static flag set to false the compiler removes the line completely, so there is no performance hit at all. Thanks David. -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 14, 2001 5:24 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java User: chirino Date: 01/11/13 20:24:08 Added: src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java Log: Factored out a CacheStore object from the message store. This should lay the ground work needed so that the MessageCache can use a PM for saving and loading messages. Also fixed a small bug in the file PM. It was not properly restoring the message after a server restart. Revision ChangesPath 1.1 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java Index: CacheStore.java === /* * JBoss, the OpenSource J2EE webOS * * Distributable under LGPL license. * See terms of license at gnu.org. */ package org.jboss.mq.pm.file; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import javax.jms.JMSException; import org.jboss.mq.SpyJMSException; import org.jboss.mq.SpyMessage; import org.jboss.mq.server.MessageReference; import org.jboss.system.ServiceMBeanSupport; /** * This class manages the persistence needs of the MessageCache * * @author Hiram Chirino * @version$Revision: 1.1 $ */ public class CacheStore extends
