James Mason wrote:
Oliver Zeigermann wrote:
Hmm, first of all I notice our line number do not match. I suppose this is because of the removal of author tags and not relevant to our problem, do you agree?
Agreed. I've been adding debugging statements and I may have forgetten to remove a few.
I see what you mean and I really wonder why the connection never is closed. Are you using compression mode?
I'm not using compression at the moment. I don't suppose the fact that there's no content could be affecting the way the input stream is handled? I looked, and it doesn't seem like it. The reason I mention this is WebFolders seems to do one of two things when uploading a file. It either executes a HEAD then PUT, or it executes PUT, PROPFIND, GET then PUT with the first PUT having no body.
I do think an empty input stream should be any different from a non-empty one, but I really do not know. A possible scenario might be the JDBC driver sees the BLOB is empty and does not request it from the DB in the fist place. Who knows? I guess in those complex scenarios almost everything is possible.
Oliver
-James
When looking at method retrieveRevisionContent in StandardRDBMSAdapter (the one MySQLAdapter uses as well) the connection gets closed by
if (temporaryConnection) {
// XXX is needed, as calling store does not know if connection should be closed now
connection.close();
}
If you do not use compression the connection will be closed inside of JDBCAwareInputStream which will be copied in GetMethod.copy
So, this seems to be alright (at least for me).
I, however, notice the original input stream from the BLOB never gets closed in compression mode. In MS SQLServer (my default DB) this seems to be done when the statement or resultset gets closed, but maybe not with MySQL. Maybe MySQL can not free the connection as long as the input stream has not been closed? Simply do not know. Please test by switchting over to non compressed mode (if you use it in the first place).
Hope this helps and we get closed to get this solved...
Oliver
James Mason wrote:
Well, I think I know what's happening now. Here's a stack trace from a failed GET:
java.lang.Throwable
at org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter.retrieveRevisionContent(StandardRDBMSAdapter.java:726)
at org.apache.slide.store.impl.rdbms.AbstractRDBMSStore.retrieveRevisionContent(AbstractRDBMSStore.java:734)
at org.apache.slide.store.AbstractStore.retrieveRevisionContent(AbstractStore.java:1314)
at org.apache.slide.store.ExtendedStore.retrieveRevisionContent(ExtendedStore.java:492)
at org.apache.slide.content.ContentImpl.retrieve(ContentImpl.java:352)
at org.apache.slide.content.ContentImpl.retrieve(ContentImpl.java:322)
at org.apache.slide.webdav.method.GetMethod.executeRequest(GetMethod.java:218)
If you compare line numbers with the code you'll notice that this request is happening outside of a transaction. Line 1287 in AbstractStore (isForceStoreEnlistment(uri)) is returning false. What ends up happening is all the classes assume someone else will end up closing the connection, and it never gets closed. If I set the max pool size to 1 GetMethod never returns.
I'll look into why SlideToken doesn't think it's part of a transaction, but I figured you might be able to find it faster :).
-James
Oliver Zeigermann wrote:
James Mason wrote:
More below.
Oliver Zeigermann wrote:
Another thing you may want to try. In org.apache.slide.store.impl.rdbms.AbstractRDBMSStore when there is a read only request outside of a transaction a new connection is retrieved from the pool, the request is done and the connection closed. Maybe MySQL needs a commit or rollback before the connection close? Maybe it starts a transaction even with a read request? I do not know. To be on the save side try to add it and do it quick replace:
connection.close();
with
connection.commit(); connection.close();
But leave sequence methods as they are.
I modified retrieveObject() in AbstractRDBMSStore. Is this the method you meant? I haven't noticed any change in behavior.
Try this modification with *all* connection.close() statements in AbstractRDBMSStore, except the ones for sequences.
Oliver
Oliver Zeigermann wrote:
All this is in one transaction? Only a single client? Then a *real* deadlock is indeed unlikely.
There is a pre-check outside of the real transaction to see if the resource you request is a collection. If so a HTML page will be generated. Maybe this is the source of the problem. To check, please comment out that check and see if it works. The check is done in org.apache.slide.webdav.WebdavServlet in line 153 with isCollection(req). Try replacing it with false for the test.
Tried this too. Didn't help.
Do not mean to let you down, but this was my last idea. Isn't there anyone out there experiencing the same? You can't be the only one using MySQL...
I'm going to try to figure out when/where the second connection is getting opened. Let me know if you think of anything else I could try.
Please tell if there is anything I can do to help you with this.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
