[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] Fixes...



Greetings

I worked on it all day yesterday and changing the brackets does not seem to work properly...

I will spend the day on it today and see what I can figure out.

Basically if I take the brackets out it fails randomly.

I am getting closer to finding whats wrong and am throwing ldbc into full debug mode today to see what I can figure.

Regards


Michele Laghi wrote:
Hi Peter,
sorry for the late answer. The removing of the brackets which you suggest would change the logics.


I would do change it by letting one parentesis. If the original request was

a AND b AND ( c OR ( d AND e) )
I would change to:
a AND b AND ( d AND e OR c)

The method invoking this function was erroneously set to deprecated. It is still used in the cache queue during the recovery process.

In removeEntriesWithLimit you also have nested brackets in the delete statement. Does that work for you ?

Michele


Peter Bennett wrote:

Greetings Michele

You missed this change...

JdbcManagerCommonTable
getEntriesWithLimit
Line 2179

Remove perenthasis for ldbc to pass it properly...
ldbc seems to figure it out... Are the tests extensive enough
to prove this does not break anything. I also note that the method that
calls getEntriesWithLimit is deprecated. ?????

String req = "SELECT * from " + this.entriesTableName + " WHERE
queueName='" + queueName + "' AND nodeId='" + nodeId + "' AND prio >
" + limitPrio + " OR prio = " + limitPrio + " AND dataId < " + limitId + "ORDER BY prio DESC, dataid ASC";


This change may be best affected using the switch nestedBracketsSupported

Regards


Michele Laghi wrote:

I implemented this change. Note that there is a difference in the exception handling from what you suggested. I tested it with oracle hsqldb and postgres (all without ldbc) and they all worked fine.

The changes are on the development branch, so what I suggest is that you go to another directory (or you delete your $XMLBLASTER_HOME), and checkout with the following command:

checkout -r DEV_085 xmlBlaster

you can find addional information on cvs on

http://www.xmlblaster.org/xmlBlaster/doc/howto/README.cvs

Could you please run the testsuite with ldbc + mySQL to see if it works ?

Michele


Peter Bennett wrote:

Greetings Michele...

I would if I could however I am not an expert with cvs and the devel branch is got me stumped.

I am not sure if I submit anything using gcvs that it is going to go to the right place.

I note last time I did it did not go to the right place.

Sorry for my ignorance...

Regards


Michele Laghi wrote:

Hi Peter,
great that it works even with mySql. Could you please connect the code in the development branch ? I think alternative (a) is the better one.


Once you have committed I would run the tests with oracle hsqldb and postgres (without ldbc).

Regards
Michele


Peter Bennett wrote:

Greetings Michele

I now pass all tests with both MySQL and Postgres including Manually
running org.xmlBlaster.test.classtest.queue.JdbcQueueTest.

There are a couple of minor fixes to code that I need....

As follows...

JdbcManagerCommonTable
deleteEntry()

Basically ldbc/MySQL spits the dummy on the prepared statement after a
rollback. ldbc/postgres is fine... Changing the code to use update works
for both. Can you (a) change to this method for all. (b) Change it so
ldbc uses the update method instead of a prepared statement.




// Connection conn = null;
// PreparedStatement st = null;
try {
// String req = "delete from " + this.entriesTableName + " where
queueName=? AND nodeId=? AND dataId=?";
// String req = "update " + this.entriesTableName + " SET
durable='X' where queueName=? AND nodeId=? AND dataId=?";
// conn = this.pool.getConnection();
// st = conn.prepareStatement(req);
// st.setString(1, queueName);
// st.setString(2, nodeId);
// st.setLong(3, uniqueId);
// return st.executeUpdate();
String req = "delete from " + this.entriesTableName + "
where queueName='"+queueName+"' AND nodeId='"+nodeId+"' AND
dataId='"+uniqueId+"'";
return update(req);
}
catch (XmlBlasterException ex) {
throw ex;
}
catch (Throwable ex) {
// if (checkIfDBLoss(conn, getLogId(queueName, nodeId,
"deleteEntry"), ex))
// throw new XmlBlasterException(this.glob,
ErrorCode.RESOURCE_DB_UNAVAILABLE, ME + ".deleteEntry", "", ex);
// else
throw new XmlBlasterException(this.glob,
ErrorCode.RESOURCE_DB_UNKNOWN, ME + ".deleteEntry", "", ex);
}
// finally {
// try {
// if (st != null) st.close();
// }
// catch (Throwable ex) {
// this.log.warn(ME, "deleteEntry: throwable when closing the
connection: " + ex.toString());
// }
// if (conn != null) this.pool.releaseConnection(conn);
// }



JdbcManagerCommonTable getEntriesWithLimit Line 2179

Remove perenthasis for ldbc to pass it properly...
ldbc seems to figure it out... Are the tests extensive enough
to prove this does not break anything. I also note that the method that
calls getEntriesWithLimit is deprecated. ?????


String req = "SELECT * from " + this.entriesTableName + " WHERE
queueName='" + queueName + "' AND nodeId='" + nodeId + "' AND prio > " +
limitPrio + " OR prio = " + limitPrio + " AND dataId < " + limitId + "
ORDER BY prio DESC, dataid ASC";


Here is how I set up my config...

JdbcStorage[ldbcpostgres]=org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin,\

                       url=jdbc:ldbc:postgresql://localhost/test,\
                       user=postgres,\
                       password=,\
                       connectionPoolSize=1,\
                       connectionBusyTimeout=90000,\
                       maxWaitingThreads=300,\
                       tableNamePrefix=XB_,\
                       nodesTableName=NODES,\
                       queuesTableName=QUEUES,\
                       entriesTableName=ENTRIES,\
                       dbAdmin=true,\
              cascadeDeleteSupported=false,\
              nestedBracketsSupported=false,\
              configurationIdentifier=ldbc

JdbcStorage[ldbcmysql]=org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin,\

                     url=jdbc:ldbc:mysql://localhost/xmlb,\
                     user=mysql,\
                     password=secret,\
                     connectionPoolSize=1,\
                     connectionBusyTimeout=90000,\
                     maxWaitingThreads=300,\
                     tableNamePrefix=XB_,\
                     nodesTableName=NODES,\
                     queuesTableName=QUEUES,\
                     entriesTableName=ENTRIES,\
                     dbAdmin=true,\
                cascadeDeleteSupported=false,\
            nestedBracketsSupported=false,\
            configurationIdentifier=ldbc


#StoragePlugin[JDBC][1.0]=${JdbcStorage[ldbcpostgres]} StoragePlugin[JDBC][1.0]=${JdbcStorage[ldbcmysql]}

StoragePlugin[RAM][1.0]=org.xmlBlaster.engine.msgstore.ram.MapPlugin
StoragePlugin[CACHE][1.0]=org.xmlBlaster.engine.msgstore.cache.PersistenceCachePlugin,persistentQueue=JDBC,transientQueue=RAM




persistence/topicStore/defaultPlugin=JDBC,1.0
persistence/msgUnitStore/defaultPlugin=CACHE,1.0
l
#QueuePlugin[JDBC][1.0]=${JdbcStorage[ldbcpostgres]}
QueuePlugin[JDBC][1.0]=${JdbcStorage[ldbcmysql]}

queue/subject/defaultPlugin=CACHE,1.0
queue/history/defaultPlugin=CACHE,1.0
queue/callback/defaultPlugin=CACHE,1.0
useTopicStore=true

plugin/ior/useNameService false

JdbcDriver.drivers=org.ldbc.jdbc.jdbcDriver

JdbcDriver.mapping[ldbc]=string=varchar(128),"longint=decimal(19,0)",int=int,boolean=char(1),blob=blob,pingStatement=Show

All,blobVarName=ablob,keyAttr=not null

Finally I will start on the requirements again...
They need a rework to reflect the integration...
Also the class files for the ldbc plugin could be removed from the
repository now. The ldbc.jar file also needs updating. I will use the
one from the ldbc web site instead of one compiled by me as you suggested.


Then I need to move on to hsqldb and see if it will go with ldbc...

Regards