RE: table prefix
Hi! i'm using table prefix in oracle to integrate slide tables into an existing application scheme. To do this, you could define your own prefix in database script and create synonyms with real names. this is not the better solution, but works and isn't necessary compile code. regards jah -Mensaje original- De: Richard Emberson [mailto:[EMAIL PROTECTED] Enviado el: martes, 23 de noviembre de 2004 16:22 Para: Slide Users Mailing List Asunto: Re: table prefix Var George, Yes, thats the thread. Thanks, hope someone in the Slide project will help. Richard Var George wrote: Richard Are you talking about the following thread? http://www.mail-archive.com/slide-user@jakarta.apache.org/msg08307.html I did all the changes (mostly per Oliver's suggestions thanks Oliver!) and it is working well for me. I wanted to submit these changes so that slide dev team may add it as a standard feature in slide but I am still waiting to hear from slide team on what is the acceptable solution for fixing RDBMSComparableResourcesPool.java. This is the only file that has SQL outside Adapter classes so I am not really sure how this class is used or if its required. The above link was my last email on it but I haven't heard from Unico or anyone . If someone in slide team can point me to an acceptable solution then I will be glad to make/test those changes and send the updated source regards Varughese George Richard Emberson [EMAIL PROTECTED] wrote: A little while ago someone was suggesting that they were working on adding a feature that would allow one to specify a database table prefix (to be used by all Slide tables) which would be used both by the initialization sql and the java code. Is that work happening? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - 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]
Re[2]: WebDAV JCA status=STATUS_NO_TRANSACTION
Hello!
The output of example with jboss 3.2.5:
Tx: [EMAIL PROTECTED]
Factory: [EMAIL PROTECTED]
Connection1: [EMAIL PROTECTED]
WR1: http://localhost:80/upload/
WR2: http://localhost:80/upload/
WR1 sees Content
WR2 sees this before commitContent
WR2 sees this after commit Content
The result of my test with jboss 3.2.5 is the same as with jboss 4.0.0
Tuesday, November 23, 2004, 11:58:41 PM, you wrote:
OZ Did the example work for you? I had the connector running with 3.x.x,
OZ no idea if it works with JBoss 4.0...
OZ Maybe Ryan has more knowledge...
OZ Oliver
OZ On Tue, 23 Nov 2004 20:04:39 +0200, Andrew Tibets
OZ [EMAIL PROTECTED] wrote:
Hello!
I used WebDAV JCA Connector Jakarta Slide 2.1beta1 in xa-transaction.
Jboss 4.0
webdav-connector-ds.xml:
?xml version=1.0 encoding=UTF-8?
connection-factories
tx-connection-factory
jndi-nameWebDAV-Connector/jndi-name
xa-transaction/
rar-namewebdav-2.1b2.rar/rar-name
connection-definitionjavax.resource.cci.ConnectionFactory/connection-definition
max-pool-size20/max-pool-size
blocking-timeout-millis5000/blocking-timeout-millis
idle-timeout-minutes15/idle-timeout-minutes
/tx-connection-factory
/connection-factories
FileServiceSessionBean: (stateless session)
private static final String HOST = http://localhost:80/upload/;;
private static final String USER = root;
private static final String PASSWORD = root;
private static final int TIMEOUT = 10;
public void createFile() {
WebDAVConnection conn1 = null;
try {
WebDAVConnectionSpec spec = new
WebDAVConnectionSpec(HOST, USER, PASSWORD, TIMEOUT);
conn1 = (WebDAVConnection) davFactory.getConnection(spec);
WebdavResource wr1 = conn1.getWebdavResource();
logger.info(mkcolMethod: +
wr1.mkcolMethod(/upload/testDir));
logger.info(putMethod: +
wr1.putMethod(/upload/testDir/newFile.txt,test data));
} catch (IOException e) {
throw new EJBException(e.getMessage(), e);
} catch (ResourceException e) {
throw new EJBException(e.getMessage(), e);
} finally {
if (conn1 != null)
try {
conn1.close();
} catch (ResourceException e) {
throw new EJBException(e.getMessage(), e);
}
}
}
createFile method has transaction attribute Required.
As a result:
19:52:28,993 ERROR [LogInterceptor]
TransactionRolledbackException in method: public abstract void
fileservice.FileServi
ceSession.createFile() throws java.rmi.RemoteException, causedBy:
org.jboss.tm.JBossRollbackException: Unable to commit,
tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=pc268/15, Branc
hQual=, localId=15] status=STATUS_NO_TRANSACTION; - nested
throwable: (javax.transaction.xa.XAException)
at
org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:344)
at
org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:457)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:149)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at
org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:854)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
I can't see what I've done wrong.
What should I do?
Thanks
--
Best regards,
Andrewmailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slide usage questions
In detail 2.2 will have much more fain grained locks which will add to the multi user scalability. Additionally, larger collections will be practical at least with certain backend stores. Oliver, what is the state of these enhancements? Is it already in the HEAD branch? If not, when will it be? Do these changes impact the 2.1 store implementations? Thanks, Peter -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Dienstag, 23. November 2004 17:05 To: Slide Users Mailing List Subject: Re: Slide usage questions More generally I can say that in Slide 2.1 there are restrictions concerning the number of concurrent users and the practical size of collections. Both restrictions have been addressed in the latest Slide code that eventually will become 2.2. In detail 2.2 will have much more fain grained locks which will add to the multi user scalability. Additionally, larger collections will be practical at least with certain backend stores. However, very large collections are discouraged anyway when accessing data over WebDAV as encoding and decoding from/to XML of collection member information really will eat up quite some time. AFAIK there is no way to retrieve only a number of children of a collection with an ordinary PROPFIND, is there? Bottom line: I *personally* would recommend Slide 2.1 for low to medium load and concurrency scenarios only. Oliver On Tue, 23 Nov 2004 07:51:10 -0800 (PST), Steve Smith [EMAIL PROTECTED] wrote: Hi all, We're looking to use slide for a key project and if you have a few moments I would like to ask a couple of questions: o In your experience (internal to your company or external) what are the largest number to concurrent user using Slide? o Similarly, what are the largest collections (number of objects or documents etc) that are managed by slide? o How responsive is end user performance? o What is the up/down time (works fine with no problems 24 x 7, goes down once a week etc) for the product and how easy or hard is it to maintenance? o What are some of the workflow options? o What environments have you seen slide running in (like WebSphere with db2, TX file system for storage) Thanks Regards - Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! - 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]
Re: Real filenames in slide tx store
The url-encode-path was originally added to enable you to save files using characters not available in your operating system. I did some testing with russian filenames and it only worked when this parameter was set to true. /jacob - Original Message - From: Warwick Burrows [EMAIL PROTECTED] To: 'Slide Users Mailing List' [EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 11:03 PM Subject: RE: Real filenames in slide tx store Thanks Oliver. Ok, I will remove it, but I thought that I set that parameter because it is needed for proper use of UTF-8 urls(??) Is that correct or have I gotten mixed up? Should I be able to use the Japanese char set without having this parameter set? Thanks, Warwick -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 3:57 PM To: Slide Users Mailing List Subject: Re: Real filenames in slide tx store You have set parameter name=url-encode-pathtrue/parameter Remove it and it will be the old behavior. Oliver On Tue, 23 Nov 2004 13:26:46 -0800, Warwick Burrows [EMAIL PROTECTED] wrote: Hi, I have a question regarding the way that content is actually physically stored in the tx filesystem store. At one time I had thought that the Slide content in the physical filesystem matched the hierarchy of the folder structure. Is that not the case anymore or have I accidentally vi done something to change this? ie. in my content store right now I only see a bunch of files like this under store/content: $ls L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDE0LzEwMDYyLzEwMDY0XzEuMA%3D%3D L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDE0LzEwMDYyLzEwMDcwLzEwMDcyXzEuMA%3D%3D L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDEwLzEwMDE2LzEwMDI3XzEuMA%3D%3D L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDEwLzEwMDE2LzEwMDIxXzEuMA%3D%3D L2hpc3RvcnkvMS9oM18xLjA%3D L2hpc3RvcnkvMS9oMF8xLjA%3D L2hpc3RvcnkvMS9oMV8xLjA%3D L2hpc3RvcnkvMS9oMl8xLjA%3D L2hpc3RvcnkvMS9oNF8xLjA%3D And I see no separate history folder with the history revisions in it. Have I changed the way that the files are physically stored in the filesystem by enabling one of the other features? Eg. UTF-8 support? I enabled the history uri hack to defray the creation of history revisions in the filesystem but this seems to be the opposite since its now storing all files including history in the one directory. This won't be performant for a large number of files and revisions. My domain.xml is included below. Sorry its so huge but I comment out what I don't need but leave it in the file so I can diff it against the 2.1 release tree. Diff it against the 2.1 release Domain.xml to see what's changed. Thanks, Warwick domain.xml ?xml version=1.0? slide logger=log4j.Log4jLogger logger-level=7 namespace name=slide definition store name=tx parameter name=cache-modeoff/parameter nodestore classname=org.apache.slide.store.impl.rdbms.JDBCStore parameter name=adapterorg.apache.slide.store.impl.rdbms.DB2RDBMSAdapt er/parameter parameter name=drivercom.ibm.db2.jcc.DB2Driver/parameter parameter name=urljdbc:db2://machine:5/DB/parameter parameter name=useruser/parameter parameter name=passwordpwd/parameter parameter name=dbcpPoolingtrue/parameter parameter name=maxPooledConnections50/parameter parameter name=isolationREAD_COMMITTED/parameter parameter name=compressfalse/parameter /nodestore sequencestore reference store=nodestore / /sequencestore securitystore reference store=nodestore / /securitystore lockstore reference store=nodestore / /lockstore revisiondescriptorsstore reference store=nodestore / /revisiondescriptorsstore revisiondescriptorstore reference store=nodestore / /revisiondescriptorstore contentstore classname=org.apache.slide.store.txfile.TxFileContentStore parameter name=rootpathstore/content/parameter parameter name=workpathwork/content/parameter parameter name=url-encode-pathtrue/parameter !-- WB: Slide user list suggested disabling this for filestore to avoid deadlock with high load -- parameter name=defer-savingfalse/parameter parameter name=timeout120/parameter /contentstore !-- uncomment if you want to use the sample Indexer -- !-- be sure to have Lucene in your classpath -- !-- contentindexer
Re: Slide usage questions
Changes to core are both in 2.1 and head branch. They pass informations about which children have been added / modified to the store implementations. Additionally, in cvs head there is a store implementation for MySQL. Oliver On Wed, 24 Nov 2004 09:33:08 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In detail 2.2 will have much more fain grained locks which will add to the multi user scalability. Additionally, larger collections will be practical at least with certain backend stores. Oliver, what is the state of these enhancements? Is it already in the HEAD branch? If not, when will it be? Do these changes impact the 2.1 store implementations? Thanks, Peter -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Dienstag, 23. November 2004 17:05 To: Slide Users Mailing List Subject: Re: Slide usage questions More generally I can say that in Slide 2.1 there are restrictions concerning the number of concurrent users and the practical size of collections. Both restrictions have been addressed in the latest Slide code that eventually will become 2.2. In detail 2.2 will have much more fain grained locks which will add to the multi user scalability. Additionally, larger collections will be practical at least with certain backend stores. However, very large collections are discouraged anyway when accessing data over WebDAV as encoding and decoding from/to XML of collection member information really will eat up quite some time. AFAIK there is no way to retrieve only a number of children of a collection with an ordinary PROPFIND, is there? Bottom line: I *personally* would recommend Slide 2.1 for low to medium load and concurrency scenarios only. Oliver On Tue, 23 Nov 2004 07:51:10 -0800 (PST), Steve Smith [EMAIL PROTECTED] wrote: Hi all, We're looking to use slide for a key project and if you have a few moments I would like to ask a couple of questions: o In your experience (internal to your company or external) what are the largest number to concurrent user using Slide? o Similarly, what are the largest collections (number of objects or documents etc) that are managed by slide? o How responsive is end user performance? o What is the up/down time (works fine with no problems 24 x 7, goes down once a week etc) for the product and how easy or hard is it to maintenance? o What are some of the workflow options? o What environments have you seen slide running in (like WebSphere with db2, TX file system for storage) Thanks Regards - Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: WebDAV JCA status=STATUS_NO_TRANSACTION
Why didn't you use the default ds definition shipped with Slide? In
webdavclient/etc/conf/connector/jboss/webdav-connector-ds.xml
?xml version=1.0 encoding=UTF-8?
connection-factories
tx-connection-factory
jndi-nameWebDAV-Connector/jndi-name
xa-transaction/
adapter-display-nameWebDAV-Connector/adapter-display-name
/tx-connection-factory
/connection-factories
With JBoss it is important to use the adapter-display-name to
associate it with the connector. A bit silly, but this is the way it
works. Thus add
adapter-display-nameWebDAV-Connector/adapter-display-name
to your ds config and try again...
Oliver
On Wed, 24 Nov 2004 10:31:23 +0200, Andrew Tibets
[EMAIL PROTECTED] wrote:
Hello!
The output of example with jboss 3.2.5:
Tx: [EMAIL PROTECTED]
Factory: [EMAIL PROTECTED]
Connection1: [EMAIL PROTECTED]
WR1: http://localhost:80/upload/
WR2: http://localhost:80/upload/
WR1 sees Content
WR2 sees this before commitContent
WR2 sees this after commit Content
The result of my test with jboss 3.2.5 is the same as with jboss 4.0.0
Tuesday, November 23, 2004, 11:58:41 PM, you wrote:
OZ Did the example work for you? I had the connector running with 3.x.x,
OZ no idea if it works with JBoss 4.0...
OZ Maybe Ryan has more knowledge...
OZ Oliver
OZ On Tue, 23 Nov 2004 20:04:39 +0200, Andrew Tibets
OZ [EMAIL PROTECTED] wrote:
Hello!
I used WebDAV JCA Connector Jakarta Slide 2.1beta1 in xa-transaction.
Jboss 4.0
webdav-connector-ds.xml:
?xml version=1.0 encoding=UTF-8?
connection-factories
tx-connection-factory
jndi-nameWebDAV-Connector/jndi-name
xa-transaction/
rar-namewebdav-2.1b2.rar/rar-name
connection-definitionjavax.resource.cci.ConnectionFactory/connection-definition
max-pool-size20/max-pool-size
blocking-timeout-millis5000/blocking-timeout-millis
idle-timeout-minutes15/idle-timeout-minutes
/tx-connection-factory
/connection-factories
FileServiceSessionBean: (stateless session)
private static final String HOST = http://localhost:80/upload/;;
private static final String USER = root;
private static final String PASSWORD = root;
private static final int TIMEOUT = 10;
public void createFile() {
WebDAVConnection conn1 = null;
try {
WebDAVConnectionSpec spec = new
WebDAVConnectionSpec(HOST, USER, PASSWORD, TIMEOUT);
conn1 = (WebDAVConnection) davFactory.getConnection(spec);
WebdavResource wr1 = conn1.getWebdavResource();
logger.info(mkcolMethod: +
wr1.mkcolMethod(/upload/testDir));
logger.info(putMethod: +
wr1.putMethod(/upload/testDir/newFile.txt,test data));
} catch (IOException e) {
throw new EJBException(e.getMessage(), e);
} catch (ResourceException e) {
throw new EJBException(e.getMessage(), e);
} finally {
if (conn1 != null)
try {
conn1.close();
} catch (ResourceException e) {
throw new EJBException(e.getMessage(), e);
}
}
}
createFile method has transaction attribute Required.
As a result:
19:52:28,993 ERROR [LogInterceptor]
TransactionRolledbackException in method: public abstract void
fileservice.FileServi
ceSession.createFile() throws java.rmi.RemoteException, causedBy:
org.jboss.tm.JBossRollbackException: Unable to commit,
tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=pc268/15, Branc
hQual=, localId=15] status=STATUS_NO_TRANSACTION; - nested
throwable: (javax.transaction.xa.XAException)
at
org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:344)
at
org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:457)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:325)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:149)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at
org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:854)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
I can't see what I've done wrong.
What should I do?
Thanks
--
Best regards,
Andrewmailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
slide clustering support question
I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc store for properties, users, groups, roles and security 1) In such a scenario how would the locks on the filesystem behave, I guess that the transaction support in the commons.transaction.file package would be broken for there would be two or more instances of FileResourceManager accessing the same directory or am I missing something ? 2) For ideal clustering support would I be confined to the JDBC store? 3) If the Tx Store still works in this configuration how does slide solve the above distributed transaction problem? Alessandro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: annotating multi-version file
Thank you! Problem solved. -Jussi On Tue, 23 Nov 2004 09:34:19 -0800, Warwick Burrows [EMAIL PROTECTED] wrote: When a file is under version control you can't change the content or the metadata without having first checked the file out. You also need to check it back in after modifying its properties. Warwick -Original Message- From: Jussi Vaihia [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 6:01 AM To: Slide Users Mailing List Subject: annotating multi-version file How does one add annotations for a file that has multiple versions ? Currently I am able to annotate a file with no version information without problems, however adding another version for the file gives 403 errors during annotation addition. http8080-Processor4, 23-Nov-2004 13:37:10, jussiava2, PROPFIND, 207 Multi-Status, 19 ms, /pdc/centre456/group655/deliv3414/a document for testing.doc http8080-Processor3, 23-Nov-2004 13:37:11, jussiava2, PROPPATCH, 403 Forbidden, 29 ms, /pdc/centre456/group655/deliv3414/a document for testing.doc Any ideas to the cause of these forbidden errors? ACL rights are all for the user (jussiava2) -- and there's no problems until versioning kicks in. -Jussi - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
use of COMPRESS flag not detected on get...
Hi I notice that if you use COMPRESS=true in the store (Oracle, in my case), and then later change it to false, any files putMethod'd into the store while COMPRESS was true will not be able to getMethod'd. ie, slide will attempt to do a getMethod assuming the files are stored in the *current* format specified in the domain.xml for the store. ie, it will attempt to pull them down in compressed (zip format), which will not work. Is this the case ? If so, is there a way to tell Slide to pull the document out in the currently stored format, not just what the domain.xml says ? Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: annotating multi-version file
I think you are looking to make Slide do something that contradicts how the Version control specification operates. The only thing I could possibly suggest is this theoretical sequence of events. 1. Remove the resource from being under version control. 2. Make the modifications to the metadata. 3. Place the resource back under version control. I say that is theoretical, because I don't know if you can remove a resource from version control. I did successfully remove the D:auto-version property using PROPPATCH, but I didn't check whether or not I was then able to alter properties without a version being created. I'm also not sure how to tell that a resource is under version control. Tim Jussi Vaihia wrote on 24/11/04 09:54 AM: A quick follow-up; CHECKIN/CHECKOUT seems to always create a new version of the document. How can this be prevented, as the change is only to metadata (annotation) ? On Tue, 23 Nov 2004 09:34:19 -0800, Warwick Burrows [EMAIL PROTECTED] wrote: When a file is under version control you can't change the content or the metadata without having first checked the file out. You also need to check it back in after modifying its properties. Warwick - 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]
RE: Real filenames in slide tx store
So when using the Russian codeset it would create the subdirectory hierarchy
instead of putting all the files in one directory? Or did you have to
accept this limitation to get the Russian codeset working? It must be a
limitation of the class that this boolean is passed to is it?
Warwick
-Original Message-
From: Jacob Lund [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 24, 2004 2:53 AM
To: Slide Users Mailing List
Subject: Re: Real filenames in slide tx store
The url-encode-path was originally added to enable you to
save files using
characters not available in your operating system. I did some
testing with
russian filenames and it only worked when this parameter was
set to true.
/jacob
- Original Message -
From: Warwick Burrows [EMAIL PROTECTED]
To: 'Slide Users Mailing List' [EMAIL PROTECTED]
Sent: Tuesday, November 23, 2004 11:03 PM
Subject: RE: Real filenames in slide tx store
Thanks Oliver. Ok, I will remove it, but I thought that I set that
parameter
because it is needed for proper use of UTF-8 urls(??) Is
that correct or
have I gotten mixed up? Should I be able to use the
Japanese char set
without having this parameter set?
Thanks,
Warwick
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 23, 2004 3:57 PM
To: Slide Users Mailing List
Subject: Re: Real filenames in slide tx store
You have set
parameter name=url-encode-pathtrue/parameter
Remove it and it will be the old behavior.
Oliver
On Tue, 23 Nov 2004 13:26:46 -0800, Warwick Burrows
[EMAIL PROTECTED] wrote:
Hi,
I have a question regarding the way that content is actually
physically stored in the tx filesystem store. At one time I had
thought that the Slide content in the physical filesystem
matched the
hierarchy of the folder structure. Is that not the case
anymore or
have I accidentally vi done something to change this? ie. in my
content store right now I only see a bunch of files like
this under
store/content:
$ls L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDE0LzEwMDYyLzEwMDY0XzEuMA%3D%3D
L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDE0LzEwMDYyLzEwMDcwLzEwMDcyXzEuMA%3D%3
D
L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDEwLzEwMDE2LzEwMDI3XzEuMA%3D%3D
L2ZpbGVzLzEwMDAwLzEwMDA3LzEwMDEwLzEwMDE2LzEwMDIxXzEuMA%3D%3D
L2hpc3RvcnkvMS9oM18xLjA%3D
L2hpc3RvcnkvMS9oMF8xLjA%3D
L2hpc3RvcnkvMS9oMV8xLjA%3D
L2hpc3RvcnkvMS9oMl8xLjA%3D
L2hpc3RvcnkvMS9oNF8xLjA%3D
And I see no separate history folder with the history
revisions in it.
Have I changed the way that the files are physically
stored in the
filesystem by enabling one of the other features? Eg. UTF-8
support? I
enabled the history uri hack to defray the creation of history
revisions in the filesystem but this seems to be the
opposite since
its now storing all files including history in the one
directory. This
won't be performant for a large number of files and revisions.
My domain.xml is included below. Sorry its so huge but I
comment out
what I don't need but leave it in the file so I can diff
it against
the 2.1 release tree. Diff it against the 2.1 release
Domain.xml to
see what's changed.
Thanks,
Warwick
domain.xml
?xml version=1.0?
slide logger=log4j.Log4jLogger logger-level=7
namespace name=slide
definition
store name=tx
parameter name=cache-modeoff/parameter
nodestore
classname=org.apache.slide.store.impl.rdbms.JDBCStore
parameter
name=adapterorg.apache.slide.store.impl.rdbms.DB2RDBMSAdapt
er/parameter
parameter
name=drivercom.ibm.db2.jcc.DB2Driver/parameter
parameter
name=urljdbc:db2://machine:5/DB/parameter
parameter name=useruser/parameter
parameter name=passwordpwd/parameter
parameter name=dbcpPoolingtrue/parameter
parameter
name=maxPooledConnections50/parameter
parameter
name=isolationREAD_COMMITTED/parameter
parameter name=compressfalse/parameter
/nodestore
sequencestore
reference store=nodestore /
/sequencestore
securitystore
reference store=nodestore /
/securitystore
lockstore
reference store=nodestore /
/lockstore
revisiondescriptorsstore
reference store=nodestore /
/revisiondescriptorsstore
revisiondescriptorstore
reference store=nodestore /
/revisiondescriptorstore
RE: slide clustering support question
We've implemented that configuration: a jdbc nodestore with tx filesystem store much like you've outlined with a HTTP load balancer between our DAV clients and Slide servers. It is untested in this target (load balanced) configuration but we have tested in a simpler configuration that shares the jdbc store and the content (using NFS) between two Slide servers. Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue. So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing store definition. So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM To: Slide Users Mailing List Subject: slide clustering support question I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc store for properties, users, groups, roles and security 1) In such a scenario how would the locks on the filesystem behave, I guess that the transaction support in the commons.transaction.file package would be broken for there would be two or more instances of FileResourceManager accessing the same directory or am I missing something ? 2) For ideal clustering support would I be confined to the JDBC store? 3) If the Tx Store still works in this configuration how does slide solve the above distributed transaction problem? Alessandro - 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]
RE: major deadlock issues (JDBC store with MySQL)
Great work Oliver! I'll grab that fix too. You can never have too many deadlock fixes, I always say ;-) Warwick -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:46 AM To: Slide Users Mailing List Subject: Re: major deadlock issues (JDBC store with MySQL) Inside security code I have found an additional request which was done outside of the transaction which explains why the locking in the WebDAV layer failed: different transactions inside the same requests where blocking each other. Now everything should be done in one and a single request. The new testcase passes now, Mirko, would you do us all the favor and check out the latest sources either from release or head branch and see if your test case succeeds as well? If not please supply stack traces and hints how to use your JMeter tests. Thanks, Oliver On Wed, 24 Nov 2004 00:53:01 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: I just could reproduce the problem with the new test case testsuite/junit/xmltestcases/functional/extra/multi-user/getPut/getPut Folder.xml and it also exists in the latest sources. It has got something to do with security and seems to be what Warwick already identified in http://issues.apache.org/bugzilla/show_bug.cgi?id=31907 which we thought was solved, but apparently is not. I will have a look at this ASAP. Oliver On Fri, 19 Nov 2004 15:59:22 -0800, Mirko Froehlich [EMAIL PROTECTED] wrote: I did some basic JMeter concurrency testing to validate if Slide meets our concurrency requirements. Unfortunately, the results were not very promising. As I mentioned, we are planning on using Slide as a repository for application data. We expect to have a few hundred concurrent users of our application who would be reading from as well as (although less frequently) writing to the repository. In case it matters, most of the read and write access would be to a dedicated folder per user, rather than a shared folder. I realize that this use case is probably very different from the way most people use Slide, which I assume is mostly for web publishing. My test mainly consists of a JSP page that uses the WebDAV client library to access a folder, iterate over the 10 contained documents and retrieve their contents (about 2k each), and create a new document, retrieve it, and then delete it. I have 100 different folders, all populated with the same 10 documents. My JMeter test consists of 5 concurrent threads that each access a different one of the 100 folders, with 800ms between requests. After only a few seconds, Slide completely deadlocks with various exceptions to that effect in the Tomcat logs. I have tried increasing my JDBC store's MySQL connection pool from 10 to 30, without any improvements. It seems like creating documents is responsible for the deadlocks, as the test behaved fine when it was limited to read-only access. Can anyone think of a way for me to tune the system in order to prevent the deadlocks from occurring? -Mirko - 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]
Re: Real filenames in slide tx store
A few months ago I added a new paramater that indicates that portable
paths should be used. We were having problems storing Japanese file
names on Windows and then migrating the store to Linux.
It uses a technique similar to url-encode-path (base64 encode, then
url encode), but it only encodes non-latin paths and encodes each path
segment to avoid all files being contained in a single directory. It
also limits file length for files stored to the filesytem to 128
characters, using an MD5 hash of the filename to ensure uniqueness
when truncating.
I have always meant to contribute this code and it sounds like now may
be the time. I have my changes against the SLIDE_2_1_M1_RELEASE tag.
I attached the patches for the 2 modified files. I'm happy to create
a bug report and if that is preferred.
--Andy
On Wed, 24 Nov 2004 09:52:44 +0100, Jacob Lund [EMAIL PROTECTED] wrote:
The url-encode-path was originally added to enable you to save files using
characters not available in your operating system. I did some testing with
russian filenames and it only worked when this parameter was set to true.
/jacob
Index: AbstractTxFileStoreService.java
===
RCS file:
/home/cvspublic/jakarta-slide/src/stores/org/apache/slide/store/txfile/AbstractTxFileStoreService.java,v
retrieving revision 1.12
diff -w -u -r1.12 AbstractTxFileStoreService.java
--- AbstractTxFileStoreService.java 10 May 2004 08:23:26 - 1.12
+++ AbstractTxFileStoreService.java 24 Nov 2004 16:53:03 -
@@ -62,6 +62,7 @@
protected static final String TIMEOUT_PARAMETER = timeout;
protected static final String URLENCODE_PATH_PARAMETER = url-encode-path;
protected static final String DEBUG_MODE_PARAMETER = debug;
+protected static final String USE_PORTABLE_PATH_PARAMETER =
use-portable-path;
protected FileResourceManager rm;
protected boolean started = false;
@@ -99,11 +100,19 @@
urlEncodePath = true.equals(urlEncodePathString);
}
+ boolean usePortablePath = false;
+ String usePortablePathString = (String)
parameters.get(USE_PORTABLE_PATH_PARAMETER);
+ if (usePortablePathString != null) {
+ usePortablePath = true.equals(usePortablePathString);
+ }
+
+ int pathEncoding = (urlEncodePath) ?
FileResourceManager.ENCODE_PATH_URL : (usePortablePath ?
FileResourceManager.ENCODE_PATH_PORTABLE :
FileResourceManager.ENCODE_PATH_NONE);
+
rm =
new FileResourceManager(
storeDir,
workDir,
-urlEncodePath,
+pathEncoding,
new StoreLogger(getLogger(),
FileResourceManager.class.getName()),
debug);
Index: FileResourceManager.java
===
RCS file:
/home/cvspublic/jakarta-slide/src/stores/org/apache/slide/store/txfile/rm/impl/Attic/FileResourceManager.java,v
retrieving revision 1.11
diff -w -u -r1.11 FileResourceManager.java
--- FileResourceManager.java10 May 2004 08:12:45 - 1.11
+++ FileResourceManager.java24 Nov 2004 16:54:05 -
@@ -1,5 +1,5 @@
/*
- * $Header:
/home/cvspublic/jakarta-slide/src/stores/org/apache/slide/store/txfile/rm/impl/Attic/FileResourceManager.java,v
1.11 2004/05/10 08:12:45 ozeigermann Exp $
+ * $Header:
/home/cvspublic/jakarta-slide/src/stores/org/apache/slide/store/txfile/rm/impl/FileResourceManager.java,v
1.11 2004/05/10 08:12:45 ozeigermann Exp $
* $Revision: 1.11 $
* $Date: 2004/05/10 08:12:45 $
*
@@ -186,7 +186,6 @@
protected String workDir;
protected String storeDir;
-protected boolean urlEncodePath = false;
protected boolean cleanUp = true;
protected boolean dirty = false;
protected int operationMode = OPERATION_MODE_STOPPED;
@@ -199,6 +198,25 @@
protected List globalOpenResources;
protected LockManager lockManager;
+public static final int ENCODE_PATH_NONE = 0;
+public static final int ENCODE_PATH_URL = 1;
+public static final int ENCODE_PATH_PORTABLE = 2;
+
+public static final int MAX_PORTABLE_FILENAME = 128;
+
+protected int encodeMode = ENCODE_PATH_NONE;
+
+/**
+ * MD5 message digest provider.
+ */
+protected static java.security.MessageDigest md5Helper;
+
+
+/**
+ * The MD5 helper object for this class.
+ */
+protected static final org.apache.util.MD5Encoder md5Encoder = new
org.apache.util.MD5Encoder();
+
/*
* --- ctor and general getter / setter methods ---
*
@@ -222,18 +240,50 @@
*
* @param storeDir directory where main data should go after commit
* @param workDir directory where transactions store temporary data
+ * @param encodeMode specifies the encoding to use for file paths
+ * written to the filesystem, either ENCODE_PATH_NONE,
+ * ENCODE_PATH_URL, or ENCODE_PATH_PORTABLE.
Re: slide clustering support question
What I was really concerned about were the filesystem locks, in your case NFS, that the txStore has to mantain on each node of the cluster to support transactions for file accesses, both stores are indeed accessing the same filesystem thus violating the rule one FileResourceManager per directory. If this holds true then even disabling all caches does not guarantee atomic operations on files, ie file transactions are not reliable. Warwick Burrows wrote: We've implemented that configuration: a jdbc nodestore with tx filesystem store much like you've outlined with a HTTP load balancer between our DAV clients and Slide servers. It is untested in this target (load balanced) configuration but we have tested in a simpler configuration that shares the jdbc store and the content (using NFS) between two Slide servers. Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue. So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing store definition. So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM To: Slide Users Mailing List Subject: slide clustering support question I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc store for properties, users, groups, roles and security 1) In such a scenario how would the locks on the filesystem behave, I guess that the transaction support in the commons.transaction.file package would be broken for there would be two or more instances of FileResourceManager accessing the same directory or am I missing something ? 2) For ideal clustering support would I be confined to the JDBC store? 3) If the Tx Store still works in this configuration how does slide solve the above distributed transaction problem? Alessandro - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: table prefix
Var George, RDBMSComparableResourcesPool is used in org.apache.slide.store.impl.rdbms.expression.RDBMSExpressionFactory which has the following javadoc: DASL Basic search expression factory that compiles query expressions to native SQL queries While we do not plan to use DASL, for completeness one would like (and I assume the Slide folks would require) this to work with table prefixes. How did you implement adding the prefix to the table names in the java code and in the sql scripts. Did you use Ants ability to filter files and copy all of the sources to a generated-source directory having Ant replace a table prefix like @TABLE_PREFIX@ with either the empty string or with a supplied prefix string (like SLIDE_)? Richard Var George wrote: Richard Are you talking about the following thread? http://www.mail-archive.com/slide-user@jakarta.apache.org/msg08307.html I did all the changes (mostly per Oliver's suggestions thanks Oliver!) and it is working well for me. I wanted to submit these changes so that slide dev team may add it as a standard feature in slide but I am still waiting to hear from slide team on what is the acceptable solution for fixing RDBMSComparableResourcesPool.java. This is the only file that has SQL outside Adapter classes so I am not really sure how this class is used or if its required. The above link was my last email on it but I haven't heard from Unico or anyone . If someone in slide team can point me to an acceptable solution then I will be glad to make/test those changes and send the updated source regards Varughese George Richard Emberson [EMAIL PROTECTED] wrote: A little while ago someone was suggesting that they were working on adding a feature that would allow one to specify a database table prefix (to be used by all Slide tables) which would be used both by the initialization sql and the java code. Is that work happening? Thanks. Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: slide clustering support question
Can anyone speculate as to how any of these distributed caches actually perform though? I'm wondering how much overhead the network communication between cluster participants introduces and whether a many-to-one (slide-to-filesystem) design using an NFS mounted filesystem wouldn't be just as fast as a many-to-many design where each slide has its own filesystem. Warwick -Original Message- From: Richard Emberson [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:40 AM To: Slide Users Mailing List Subject: Re: slide clustering support question Build your own or use whats out there. For Slide to have top-grade clustering either Slide must invest the time and effort to develop such a system or just use existing libraries that provide such capabilities. I would think that the correct approach is to build on whats out there, specifically, JGroups which has a distinguished academic pedigree, rich computer science heritage and significant usage. JGroups has distributed hashtables, distributed lock management, and, very appealing, group membership can be determined dynamically - one does not have to know every member of the group when the whole cluster starts. Slide might have to be refactored some so that the clustering implementation is an addon and the main Slide code can compile and run without the JGroups jar file. But for those who wish to use Slide where clustering is a must, either for performance or failover, then the clustering implementation with its dependence on JGroups would have to be compiled and loaded. Example usages: JBoss uses JGroups. CJDBC uses JGroups. Richard Warwick Burrows wrote: We've implemented that configuration: a jdbc nodestore with tx filesystem store much like you've outlined with a HTTP load balancer between our DAV clients and Slide servers. It is untested in this target (load balanced) configuration but we have tested in a simpler configuration that shares the jdbc store and the content (using NFS) between two Slide servers. Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue. So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing store definition. So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM To: Slide Users Mailing List Subject: slide clustering support question I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc store for properties, users, groups, roles and security 1) In such a scenario how would the locks on the filesystem behave, I guess that the transaction support in the commons.transaction.file package would be broken for there would be two or more instances of FileResourceManager accessing the same directory or am I missing something ? 2) For ideal clustering support would I be confined to the JDBC store? 3) If the Tx Store still works in this configuration how does slide solve the above distributed transaction problem? Alessandro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
RE: slide clustering support question
I may not understand the whole picture here but this is what I had surmised :-) We've implemented our client using exclusive write locks so that only the person who holds the DAV lock on the file can modify the file. So access to the filesystem to modify the file is synchronized through the object lock and so only one of the slide servers in the cluster will ever make the modification as long as only one DAV application can get the DAV lock. The transaction locks also seem to be implemented as standard DAV locks (they appear in the db LOCK table too) and so transaction synchronization also occurs on a DAV lock. The DAV locks are implemented in the jdbc store and updates to the lock table are synchronized by the jdbc client and will be safe -- as long as the locks aren't cluster cached and the db transaction isolation level is set appropriately. So my thought here is that even if filesystem locks are taken during file content modification by the server, the DAV lock on that object guarantees that only one user, and so one Slide server acting on their behalf, can modify the content while others reading it will continue to reference what appears to be the current version to them. So the cluster caching breaks this model by potentially allowing two servers to make a lock request at exactly the same time causing undefined behaviour. After reviewing this and fixing some bugs in the transaction code I'm now concerned about the transaction isolation level that I'm using though. READ_COMMITTED seems to indicate that other clients can continue to read the lock table to see if an object is locked while another thread is in the process of locking it. It doesn't seem like the atomic operation that is normally required to ensure that only one lock requester gets a lock. Is there anybody who knows more about how the slide server ensures that only once caller will get a lock? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:25 AM To: Slide Users Mailing List Subject: Re: slide clustering support question What I was really concerned about were the filesystem locks, in your case NFS, that the txStore has to mantain on each node of the cluster to support transactions for file accesses, both stores are indeed accessing the same filesystem thus violating the rule one FileResourceManager per directory. If this holds true then even disabling all caches does not guarantee atomic operations on files, ie file transactions are not reliable. Warwick Burrows wrote: We've implemented that configuration: a jdbc nodestore with tx filesystem store much like you've outlined with a HTTP load balancer between our DAV clients and Slide servers. It is untested in this target (load balanced) configuration but we have tested in a simpler configuration that shares the jdbc store and the content (using NFS) between two Slide servers. Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue. So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing store definition. So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM To: Slide Users Mailing List Subject: slide clustering support question I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc
RE: slide clustering support question
In the CMS that I've designed for my last company, we had a read-only cluster solution. So we had just one edit-server that allowed people to change content and some other nodes that got notified when content changed. So this is a simple solution if you want to achieve high performance read access (we used this for a large customer with very high web traffic). If you want to achieve a fail-safe edit scenario where content can be edited at each node everything is getting much more complicated (and much slower). So I think it would make no big difference in performance if the clustering is achieved by using one backend or by transaction-aware notifications. But would be nice to have a real edit-cluster without the need of a db... Cheers, Daniel Slide Users Mailing List [EMAIL PROTECTED] schrieb am 24.11.04 19:05:22: Can anyone speculate as to how any of these distributed caches actually perform though? I'm wondering how much overhead the network communication between cluster participants introduces and whether a many-to-one (slide-to-filesystem) design using an NFS mounted filesystem wouldn't be just as fast as a many-to-many design where each slide has its own filesystem. Warwick -Original Message- From: Richard Emberson [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:40 AM To: Slide Users Mailing List Subject: Re: slide clustering support question Build your own or use whats out there. For Slide to have top-grade clustering either Slide must invest the time and effort to develop such a system or just use existing libraries that provide such capabilities. I would think that the correct approach is to build on whats out there, specifically, JGroups which has a distinguished academic pedigree, rich computer science heritage and significant usage. JGroups has distributed hashtables, distributed lock management, and, very appealing, group membership can be determined dynamically - one does not have to know every member of the group when the whole cluster starts. Slide might have to be refactored some so that the clustering implementation is an addon and the main Slide code can compile and run without the JGroups jar file. But for those who wish to use Slide where clustering is a must, either for performance or failover, then the clustering implementation with its dependence on JGroups would have to be compiled and loaded. Example usages: JBoss uses JGroups. CJDBC uses JGroups. Richard Warwick Burrows wrote: We've implemented that configuration: a jdbc nodestore with tx filesystem store much like you've outlined with a HTTP load balancer between our DAV clients and Slide servers. It is untested in this target (load balanced) configuration but we have tested in a simpler configuration that shares the jdbc store and the content (using NFS) between two Slide servers. Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue. So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing store definition. So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world? Warwick -Original Message- From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM To: Slide Users Mailing List Subject: slide clustering support question I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The
Re: annotating multi-version file
Jussi, what's the metadata that you want to be able to change on the document without checking it in /out? The D:annotations ... D:annotations in the below reply. From the replies I've gathered an uglu hack seems to be only solution, as webdav isn't flexible in this manner ? --- ?xml version=1.0? A:propfind xmlns:A=DAV: A:allprop/ /A:propfind --- ?xml version=1.0 encoding=UTF-8? D:multistatus xmlns:D=DAV: D:response D:href/slide/pdc/centre456/group655/deliv3414/This%20is%20a%20word%20document%20file.doc/D:href D:propstat D:prop D:displaynameThis is a word document file.doc/D:displayname D:source / D:getlastmodifiedWed, 24 Nov 2004 13:54:32 GMT/D:getlastmodified D:getcontentlength19456/D:getcontentlength D:resourcetype / D:getcontenttypeapplication/msword/D:getcontenttype D:annotations Z:annotation xmlns:Z=http://www.test.co/webdav/namespace/annotation/; Z:authorjussiava2/Z:author Z:date24.11.04/Z:date Z:id0/Z:id Z:textbWlpb2k=/Z:text /Z:annotation Z:annotation xmlns:Z=http://www.test.co/webdav/namespace/annotation/; Z:authorjussiava2/Z:author Z:date24.11.04/Z:date Z:id1/Z:id Z:textYW5ub3RhdGluZw==/Z:text /Z:annotation /D:annotations D:getcontentlanguageen/D:getcontentlanguage D:creationdate2004-11-23T13:34:05Z/D:creationdate D:lockdiscovery / D:supportedlock D:lockentry D:lockscope D:exclusive / /D:lockscope D:locktype D:write / /D:locktype /D:lockentry D:lockentry D:lockscope D:shared / /D:lockscope D:locktype D:write / /D:locktype /D:lockentry /D:supportedlock D:modificationdate2004-11-24T14:51:04Z/D:modificationdate D:getetag59a880877ba52ecbaae0fc35b62e76a6/D:getetag /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat /D:response /D:multistatus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: major deadlock issues (JDBC store with MySQL)
This is probably no surprise, but once I enable caching (as we would in production), everything works fine. My test case consists of about 90% read-only access and 10% read/write access, which should reflect our expected usage patterns. -Mirko On Wed, 2004-11-24 at 11:21, Mirko Froehlich wrote: Unfortunately I am still getting deadlocks with the latest code from the release branch. I think my initial tests were a little too aggressive, as I was generating more requests than the server could actually handle. I have now adjusted my tests to closely match the realistic throughput that I can achieve, and I'm getting good results using the tx store. The db store still isn't happy. I still get an XAException, preceded by HeuristicMixedException, IllegalStateException, all of which result in a WebdavException (Internal server error), as well as occasional SQLException and ServiceAccessException that mention deadlocks - see below. Could someone help me get the test suite running? I'll try to reproduce the problem that way, which might simplify things. I've been able to compile the test suite, but am not sure how to configure and invoke it, as I always get a success message when I run the TProcessor, even when my Slide server is down... -Mirko Exceptions: = 24 Nov 2004 11:10:57 - org.apache.slide.transaction.SlideTransaction - WARNING - Enlist failure: Resource manager [EMAIL PROTECTED] Error code XAER_NOTA in Transaction 168 xid http-8080-Processor15-1101323457477-168- in thread http-8080-Processor15 http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 51 ms, /db/load_test/user_12/foobar_7.txt http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 39 ms, /db/load_test/user_12/foobar_6.txt http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 42 ms, /db/load_test/user_12/foobar_5.txt http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 65 ms, /db/load_test/user_12/foobar_4.txt http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 56 ms, /db/load_test/user_12/foobar_3.txt http-8080-Processor16, 24-Nov-2004 11:10:57, unauthenticated, GET, 200 OK, 163 ms, /db/load_test/user_12/foobar_2.txt 24 Nov 2004 11:10:58 - org.apache.slide.transaction.SlideTransaction - WARNING - Commit failure: Resource manager [EMAIL PROTECTED] Error code XAER_NOTA in Transaction 168 xid http-8080-Processor15-1101323457477-168- in thread http-8080-Processor15 javax.transaction.xa.XAException at org.apache.commons.transaction.util.xa.AbstractXAResource.commit(AbstractXAResource.java:69) at org.apache.slide.transaction.SlideTransaction.commit(SlideTransaction.java:300) at org.apache.slide.transaction.SlideTransactionManager.commit(SlideTransactionManager.java:186) at org.apache.slide.common.NamespaceAccessTokenImpl.commit(NamespaceAccessTokenImpl.java:423) at org.apache.slide.webdav.method.AbstractWebdavMethod.run(AbstractWebdavMethod.java:388) at org.apache.slide.webdav.WebdavServlet.service(WebdavServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.slide.webdav.filter.LogFilter.doFilter(LogFilter.java:141) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at
Re: publishing workflow / best practices
For my information, why would you not have top-level directories: dev, staging, and production; all within the same Slide server? Richard Mirko Froehlich wrote: Those of you who are using Slide in a production environment, what kind of publishing workflow have you put in place? We will likely end up using Slide for various aspects of our application. Initially, it will mostly serve as a repository for user-specific application data. In this scenario, the user data would only live on the production server and there would not have to be a publishing process that moves data from staging to production. However, there's a good chance that we may end up using Slide for web publishing as well, in which case we would probably want to be able to manage content on the staging server and push it to production as part of a publishing workflow. I suppose this could be as simple as performing a database dump on staging and loading it on production. We would probably set up multiple db stores, which would allow us to publish the part of the repository that is used for web publishing, but not the part of the repository that contains the users' application data. Anyway, I would be interested in hearing about your experiences and best practices that you have determined for these kinds of scenarios. -Mirko -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Webdav copy across Slide namespaces
Does Slides implementation of the webdav COPY method allow one to copy a resource or collection across Slide namespaces? Richard -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: publishing workflow / best practices
It sounds like writing a client tool to migrate content from one Slide server to another one might be a good option. This should be fairly simple to write using the Webdav client library. Another option that I originally had in mind is to simply perform a database dump on the staging server and upload this to production. Of course, this would preserve the entire version history, which we most likely won't care about on our production server, so a separate tool might be more appropriate. -Mirko On Wed, 2004-11-24 at 13:58, Richard Emberson wrote: I must preface my remarks by stating that our Slide deployment will use a database for storage. Consider Slide namespaces. From what I've heard and based upon the mailing list traffic, multi Slide namespace installations do not occur very often. Lets say that such installations work just fine, - each namespace could use a different database - one would need some external Slide/webdav tool/script to promote (copy) directories from dev namespace to test namespace to production namespace. Since one has to create and use such a promotion tool, its not clear that having a single Slide with three namespaces buys one anything over having three distinct Slides each with their own DB. I am assuming that to promote a directory involves getting it (the whole directory hierarchy) into the (client) tool from one Slide server and then putting into a second Slide server. This is true even if one has the three Slide databases on the same database server; one must extract the directory from one db and insert it into another. Our dev Slide server will be version controlled while the test and production need only have non-versionable copies. Mirko Froehlich wrote: Our current staging environment really serves a different purpose. Our test, staging, and production servers correspond to phases in our software development cycle and are strictly separated. We definitely wouldn't want to use the production Slide server for development or test purposes, so those at the minimum would need to be separate servers. However, my example of publishing web content from staging to production uses a different concept of staging than we currently have, so it may not be an ideal example. I suppose for this scenario the content could very well live in two different folders on the production Slide server, with a simple publishing process that copies or moves content from the staging to the production server. I guess in the end this really depends on the workflows we need. For example, for content updates on the live site this approach would probably work well. But lets say we develop a new major version of the application with significant changes to our web content management framework and corresponding new content in the repository. When this goes live, we would need to publish the content from the staging Slide server to the production server. I know this is somewhat hypothetical at this point. I'm just trying to get a feel for how people use Slide. Yours is definitely a viable option. -Mirko On Wed, 2004-11-24 at 12:58, Richard Emberson wrote: For my information, why would you not have top-level directories: dev, staging, and production; all within the same Slide server? Richard Mirko Froehlich wrote: Those of you who are using Slide in a production environment, what kind of publishing workflow have you put in place? We will likely end up using Slide for various aspects of our application. Initially, it will mostly serve as a repository for user-specific application data. In this scenario, the user data would only live on the production server and there would not have to be a publishing process that moves data from staging to production. However, there's a good chance that we may end up using Slide for web publishing as well, in which case we would probably want to be able to manage content on the staging server and push it to production as part of a publishing workflow. I suppose this could be as simple as performing a database dump on staging and loading it on production. We would probably set up multiple db stores, which would allow us to publish the part of the repository that is used for web publishing, but not the part of the repository that contains the users' application data. Anyway, I would be interested in hearing about your experiences and best practices that you have determined for these kinds of scenarios. -Mirko
Re: annotating multi-version file
Warwick Burrows wrote: I'm pretty sure that you can't remove a file from version control once it is under control. There is definitely no specified means to do so. And the Whether you can do that or not is completely implementation-dependant. RFC3253 just doesn't mention it. Many servers disable version control when you apply DELETE to the URI of the version history resource, for example. ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use of COMPRESS flag not detected on get...
On Wednesday 24 November 2004 15:51, Nick Longinow wrote: I notice that if you use COMPRESS=true in the store (Oracle, in my case), and then later change it to false, any files putMethod'd into the store while COMPRESS was true will not be able to getMethod'd. ie, slide will attempt to do a getMethod assuming the files are stored in the *current* format specified in the domain.xml for the store. ie, it will attempt to pull them down in compressed (zip format), which will not work. Is this the case ? Yes :( If so, is there a way to tell Slide to pull the document out in the currently stored format, not just what the domain.xml says ? Not now, I have made a small patch for Oracle, I'll commit it this friday in HEAD... -- Davide Savazzi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
