Tim,
Thanks for your reply.
Actually, we do not give any unique ids to the server instances. Where and how could this
be done?
To clarify, I'm not talking about some form of clustering. We are using several
independent "instances" of JBoss, that are mapped to different ports by the
ServiceBindingManager. The instances share a common Sybase database for persisting JMS
messages.
In the meantime we have explored this issue in two directions:
1. Using an instance specific sybase-persistence-service.xml, that adds a server id column
to all JMS persistence tables and uses a (hard-coded) server id in all SQL statements for
selections/updates.
2. Usage of Apache Derby: This creates an individual copy of the persistence database in
each instance's data directory. There are two problems with this approach:
a) JDBC type LONGVARBINARY (used for storing message content) is not compatible to Derby
type BLOB, but only to "LONG VARCHAR FOR BIT DATA" with a maximum length of
32700 bytes.
b) In method org.jboss.messaging.core.plugin.JDBCPersistenceManager.getBytes(ResultSet rs,
int columnIndex) the method rs.getBinaryStream() is invoked twice on the same column (line
4250). This is considered an error by Derby. Workaround: change the second usage to use
the first result (i), recompile and use the generated jboss-messaging.jar in
jboss-messaging.sar.
// is = new BufferedInputStream(rs.getBinaryStream(columnIndex), BUFFER_SIZE);
is = new BufferedInputStream(i, BUFFER_SIZE);
Both solutions seem to work (in Derby's case with the limitation that messages longer
than about 32k cannot be stored).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036982#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...