From: Joel Rosi-S. <joe...@et...> - 2003-07-29 17:38:29
|
I have read through much of the mail list in the past few days to catch up on the state of affairs. I have come across several threads that indicate problems with database corruption. The threads seem to point to locking issues, threading issues and caching/flushing issues. Are these still issues or have they been addressed? The threads seem to dangle without concrete resolution. What I am really trying to ascertain is whether eXist is ready yet for use in a production system where it is has many simultaneous readers and writers, and where it is expected to survive a system crash without data corruption. Data loss during a crash is to be expected and thus tolerated, but loss of the data store would be unacceptable. Thanks, Joel |
From: Wolfgang M. <me...@if...> - 2003-07-30 08:49:31
|
Hi again, The latest development snapshot should fix a major part of the reported problems. In particular, there have been improvements to flushing, synchronization and multi-threading. My tests with multiple client threads did not show any errors during the last weeks (however, synchronization problems might still occurr in other, yet untested use cases). I'm personally using the development version of eXist as backend for a metadata editing tool, which is already in production use. In this setting, multiple users are allowed to add, remove or update rather complex RDF metadata records, which are stored in their private home collection. The server has been running for more than a month without pause. Due to the nature of the project (it addresses german social scientists) the number of active users is still rather small (~20). However, I'm already quite happy with what we have achieved so far. See http://www.sozionet.org/wizard/MetaWizard (German language only). I have also written an eXist-based harvester to harvest the edited resources from the web. In this case, I'm using XUpdate to append the fulltext content of the corresponding web page or PDF to the RDF metadata record. After fixing several bugs during the last days, this works perfectly well. Wolfgang On Tuesday 29 July 2003 07:34 pm, Joel Rosi-Schwartz wrote: > I have read through much of the mail list in the past few days to catch > up on the state of affairs. I have come across several threads that > indicate problems with database corruption. The threads seem to point to > locking issues, threading issues and caching/flushing issues. Are these > still issues or have they been addressed? The threads seem to dangle > without concrete resolution. > > What I am really trying to ascertain is whether eXist is ready yet for > use in a production system where it is has many simultaneous readers and > writers, and where it is expected to survive a system crash without data > corruption. Data loss during a crash is to be expected and thus > tolerated, but loss of the data store would be unacceptable. |
From: Wolfgang M. <me...@if...> - 2003-07-30 10:20:50
|
I think it's really time to publish a new release. Before that, I just have to update some older parts of the documentation. In the meantime I recommend to use the dev snapshot. Wolfgang On Wednesday 30 July 2003 11:26 am, you wrote: > On Thu, Jul 31, 2003 at 04:44:23AM +0200, Wolfgang Meier wrote: > > The latest development snapshot should fix a major part of the reported > > problems. In particular, there have been improvements to flushing, > > synchronization and multi-threading. My tests with multiple client > > threads did not show any errors during the last weeks (however, > > synchronization problems might still occurr in other, yet untested use > > cases). > > Would you advice using the development snapshot over the latest released > version? |
From: Joel Rosi-S. <Joel.Rosi-Schwartz@Etish.org> - 2003-08-03 15:08:57
|
Wolfgang, Thank you for your lengthy and thoughtful reply to my question. I have spent the last couple of days setting up and testing a test application environment that utilizes eXist as the datastore. Note that my application is well down the development cycle and I have tested the same functionality extensively under Xindice, so I am fairly confident that the problems I am experiencing are due to the introduction of eXist. First off my environment is: eXist: 0.9.2 and head out of cvs (I have reproduced the problem under both) OS: linux, Red Hat 8.2 jdk: 1.4.1 JBoss: 3.2.1 I have created eXist and xmlDb services in JBoss. Basically this is created using the MBean code in third party with some modifications by Kevin O'Neill and some more by myself. The services run quite well. Since I have existing data, I create a virgin database with the command line client and load up my documents from the file system. These files are simply an export of my application data from the Xindice version. I then copy the newly created database into the proper place in the JBoss tree. Only at this point do I start JBoss up and the startup looks normal. I start my application client which queries the database via EJB service beans. All looks as expected. I create a new resource, close it and reopen it. All is fine. I browse around my project, everything looks good. Next I shut down JBoss and restart JBoss. I reconnect my client to the server and everything falls apart. After putting in a bit of diagnostics I ascertained that one of my core structural documents, the DocumentsMap, has been trashed and has no document root. This document would have had an entry inserted when I created the new resource, Btw, I do all updates at the resource level, I do not rely on Xupdate yet, so essentially the DocumentsMap resource is manipulated in memory and resaved to the database. This is pretty much a show stopper for me. Any advice on where to go from here? Shall I simply wait for the next snap shot and try it again? Is it worth sending you the virgin and corrupted databases? Thanks, Joel Wolfgang Meier wrote: >Hi again, > >The latest development snapshot should fix a major part of the reported >problems. In particular, there have been improvements to flushing, >synchronization and multi-threading. My tests with multiple client threads >did not show any errors during the last weeks (however, synchronization >problems might still occurr in other, yet untested use cases). > >I'm personally using the development version of eXist as backend for a >metadata editing tool, which is already in production use. In this setting, >multiple users are allowed to add, remove or update rather complex RDF >metadata records, which are stored in their private home collection. The >server has been running for more than a month without pause. Due to the >nature of the project (it addresses german social scientists) the number of >active users is still rather small (~20). However, I'm already quite happy >with what we have achieved so far. See >http://www.sozionet.org/wizard/MetaWizard (German language only). > >I have also written an eXist-based harvester to harvest the edited resources >from the web. In this case, I'm using XUpdate to append the fulltext content >of the corresponding web page or PDF to the RDF metadata record. After fixing >several bugs during the last days, this works perfectly well. > >Wolfgang > > >On Tuesday 29 July 2003 07:34 pm, Joel Rosi-Schwartz wrote: > > >>I have read through much of the mail list in the past few days to catch >>up on the state of affairs. I have come across several threads that >>indicate problems with database corruption. The threads seem to point to >>locking issues, threading issues and caching/flushing issues. Are these >>still issues or have they been addressed? The threads seem to dangle >>without concrete resolution. >> >>What I am really trying to ascertain is whether eXist is ready yet for >>use in a production system where it is has many simultaneous readers and >>writers, and where it is expected to survive a system crash without data >>corruption. Data loss during a crash is to be expected and thus >>tolerated, but loss of the data store would be unacceptable. >> >> > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >Exist-open mailing list >Exi...@li... >https://lists.sourceforge.net/lists/listinfo/exist-open > > > |
From: Wolfgang M. <me...@if...> - 2003-08-04 08:02:31
|
Joel, Unfortunately, my experience with JBoss is rather limited. However, it seems that we still have a shutdown problem here. eXist registers a shutdown listener to get informed about Java shutdowns. It seems, this doesn't work with JBoss running (probably eXist gets interrupted while it is flushing its buffers and thus, the files get damaged). I'm out of office for the next two days, but I will try to investigate this issue when I'm back on wednesday. In the meantime, you could try to comment out the last lines of in class org.exist.storage.BrokerPool, which register the shutdown hook. Just to see what happens. Would it be possible to add an explicit database shutdown (via org.exist.xmldb.DatabaseInstanceManager) to the mbean code? Wolfgang > Wolfgang, > > Thank you for your lengthy and thoughtful reply to my question. > > I have spent the last couple of days setting up and testing a test > application environment that utilizes eXist as the datastore. Note that > my application is well down the development cycle and I have tested the > same functionality extensively under Xindice, so I am fairly confident > that the problems I am experiencing are due to the introduction of eXist. > > First off my environment is: > eXist: 0.9.2 and head out of cvs (I have reproduced the problem > under both) > OS: linux, Red Hat 8.2 > jdk: 1.4.1 > JBoss: 3.2.1 > > I have created eXist and xmlDb services in JBoss. Basically this is > created using the MBean code in third party with some modifications by > Kevin O'Neill and some more by myself. The services run quite well. > > Since I have existing data, I create a virgin database with the command > line client and load up my documents from the file system. These files > are simply an export of my application data from the Xindice version. I > then copy the newly created database into the proper place in the JBoss > tree. > > Only at this point do I start JBoss up and the startup looks normal. I > start my application client which queries the database via EJB service > beans. All looks as expected. I create a new resource, close it and > reopen it. All is fine. I browse around my project, everything looks good. > > Next I shut down JBoss and restart JBoss. I reconnect my client to the > server and everything falls apart. After putting in a bit of diagnostics > I ascertained that one of my core structural documents, the > DocumentsMap, has been trashed and has no document root. This document > would have had an entry inserted when I created the new resource, Btw, I > do all updates at the resource level, I do not rely on Xupdate yet, so > essentially the DocumentsMap resource is manipulated in memory and > resaved to the database. > > This is pretty much a show stopper for me. Any advice on where to go > from here? Shall I simply wait for the next snap shot and try it again? > Is it worth sending you the virgin and corrupted databases? > > Thanks, > Joel > > > Wolfgang Meier wrote: > > >Hi again, > > > >The latest development snapshot should fix a major part of the reported > >problems. In particular, there have been improvements to flushing, > >synchronization and multi-threading. My tests with multiple client threads > >did not show any errors during the last weeks (however, synchronization > >problems might still occurr in other, yet untested use cases). > > > >I'm personally using the development version of eXist as backend for a > >metadata editing tool, which is already in production use. In this setting, > >multiple users are allowed to add, remove or update rather complex RDF > >metadata records, which are stored in their private home collection. The > >server has been running for more than a month without pause. Due to the > >nature of the project (it addresses german social scientists) the number of > >active users is still rather small (~20). However, I'm already quite happy > >with what we have achieved so far. See > >http://www.sozionet.org/wizard/MetaWizard (German language only). > > > >I have also written an eXist-based harvester to harvest the edited resources > >from the web. In this case, I'm using XUpdate to append the fulltext content > >of the corresponding web page or PDF to the RDF metadata record. After fixing > >several bugs during the last days, this works perfectly well. > > > >Wolfgang > > > > > >On Tuesday 29 July 2003 07:34 pm, Joel Rosi-Schwartz wrote: > > > > > >>I have read through much of the mail list in the past few days to catch > >>up on the state of affairs. I have come across several threads that > >>indicate problems with database corruption. The threads seem to point to > >>locking issues, threading issues and caching/flushing issues. Are these > >>still issues or have they been addressed? The threads seem to dangle > >>without concrete resolution. > >> > >>What I am really trying to ascertain is whether eXist is ready yet for > >>use in a production system where it is has many simultaneous readers and > >>writers, and where it is expected to survive a system crash without data > >>corruption. Data loss during a crash is to be expected and thus > >>tolerated, but loss of the data store would be unacceptable. > >> > >> > > > > > > > >------------------------------------------------------- > >This SF.Net email sponsored by: Free pre-built ASP.NET sites including > >Data Reports, E-commerce, Portals, and Forums are available now. > >Download today and enter to win an XBOX or Visual Studio .NET. > >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > >_______________________________________________ > >Exist-open mailing list > >Exi...@li... > >https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > > > -- |
From: Per N. <per...@re...> - 2003-08-04 12:11:09
|
Hi Wolfgang, Ideally the eXist shutdown hook should not be registered and used when running inside JBoss. The idea from the perspective if running JBoss as an application server is to manage the lifecycle of it's services (MBeans). The MBean lifecycle from the JBoss perspective is pretty similar to a servlet ( createService(), startService(), stopService(), destroyService() ). Services can depend on each other and for our purpose the XMLDB service depend on the eXist service. This means that when the shutdownHook is triggered, JBoss will call stopService() first on the XMLDB service and then on the eXist service, then destroyService() will be called in the same order and after this the services are subjects for gc. If there was a way to stop eXist from registering the shutdown hook such as through a parameterized configure method (e.g. configure(boolean registerShutdown) ) it would lead to cleaner code for the service IMO. Anyway, As you know when JBoss shuts down the following currently occurs: 1. the XMLDB service stops i.e. the rootCollection is closed 2. the eXist service stops i.e. BrokerPool.stop() is called. i.e. protected void stopService() throws Exception { if (BrokerPool.isConfigured()) { BrokerPool.stop(); } } Do i understand you correctly that you suggest to change this to 1. the XMLDB service stops i.e. the rootCollection is closed and databaseInstanceManager.shutdown() is called e.g. protected void stopService() throws Exception { NonSerializableFactory.unbind(this.getClass().getName()); if (baseCollection != null) { // shutdown the database gracefully DatabaseInstanceManager manager = (DatabaseInstanceManager) baseCollection.getService("DatabaseInstanceManager", "1.0"); baseCollection.close(); LOG.debug("Closed base (db) collection"); manager.shutdown(); LOG.debug("Shutdown XMLDB"); } } 2. the eXist service stops i.e. BrokerPool.stop() is called (i.e left unchanged). I think you are right in that the issue is probably that eXists gets interrupted but as far as i can tell calling shutdown from the manager gives the same result as BrokerPool.stop() so I do not understand why this would solve the problem. My limited understanding of eXists internals is stopping me from making an educated guess on this so if you would care to elaborate I would be much appreciated. Best regards, Per On Monday 04 August 2003 10.02, Wolfgang Meier wrote: > Joel, > > Unfortunately, my experience with JBoss is rather limited. However, it > seems that we still have a shutdown problem here. eXist registers a > shutdown listener to get informed about Java shutdowns. It seems, this > doesn't work with JBoss running (probably eXist gets interrupted while it > is flushing its buffers and thus, the files get damaged). > > I'm out of office for the next two days, but I will try to investigate this > issue when I'm back on wednesday. In the meantime, you could try to > comment out the last lines of in class org.exist.storage.BrokerPool, > which register the shutdown hook. Just to see what happens. > > Would it be possible to add an explicit database shutdown (via > org.exist.xmldb.DatabaseInstanceManager) to the mbean code? > > Wolfgang > > > Wolfgang, > > > > Thank you for your lengthy and thoughtful reply to my question. > > > > I have spent the last couple of days setting up and testing a test > > application environment that utilizes eXist as the datastore. Note that > > my application is well down the development cycle and I have tested > > the > > > same functionality extensively under Xindice, so I am fairly confident > > that the problems I am experiencing are due to the introduction of > > eXist. > > > First off my environment is: > > eXist: 0.9.2 and head out of cvs (I have reproduced the problem > > under both) > > OS: linux, Red Hat 8.2 > > jdk: 1.4.1 > > JBoss: 3.2.1 > > > > I have created eXist and xmlDb services in JBoss. Basically this is > > created using the MBean code in third party with some modifications > > by > > > Kevin O'Neill and some more by myself. The services run quite well. > > > > Since I have existing data, I create a virgin database with the > > command > > > line client and load up my documents from the file system. These files > > are simply an export of my application data from the Xindice version. I > > then copy the newly created database into the proper place in the > > JBoss > > > tree. > > > > Only at this point do I start JBoss up and the startup looks normal. I > > start my application client which queries the database via EJB service > > beans. All looks as expected. I create a new resource, close it and > > reopen it. All is fine. I browse around my project, everything looks > > good. > > > Next I shut down JBoss and restart JBoss. I reconnect my client to the > > server and everything falls apart. After putting in a bit of diagnostics > > I ascertained that one of my core structural documents, the > > DocumentsMap, has been trashed and has no document root. This > > document > > > would have had an entry inserted when I created the new resource, > > Btw, I > > > do all updates at the resource level, I do not rely on Xupdate yet, so > > essentially the DocumentsMap resource is manipulated in memory > > and > > > resaved to the database. > > > > This is pretty much a show stopper for me. Any advice on where to go > > from here? Shall I simply wait for the next snap shot and try it again? > > Is it worth sending you the virgin and corrupted databases? > > > > Thanks, > > Joel > > > > Wolfgang Meier wrote: > > >Hi again, > > > > > >The latest development snapshot should fix a major part of the > > reported > > > >problems. In particular, there have been improvements to flushing, > > >synchronization and multi-threading. My tests with multiple client > > threads > > > >did not show any errors during the last weeks (however, > > synchronization > > > >problems might still occurr in other, yet untested use cases). > > > > > >I'm personally using the development version of eXist as backend > > for a > > > >metadata editing tool, which is already in production use. In this > > setting, > > > >multiple users are allowed to add, remove or update rather complex > > RDF > > > >metadata records, which are stored in their private home collection. > > The > > > >server has been running for more than a month without pause. Due > > to the > > > >nature of the project (it addresses german social scientists) the > > number of > > > >active users is still rather small (~20). However, I'm already quite > > happy > > > >with what we have achieved so far. See > > >http://www.sozionet.org/wizard/MetaWizard (German language > > only). > > > >I have also written an eXist-based harvester to harvest the edited > > resources > > > >from the web. In this case, I'm using XUpdate to append the fulltext > > content > > > >of the corresponding web page or PDF to the RDF metadata record. > > After fixing > > > >several bugs during the last days, this works perfectly well. > > > > > >Wolfgang > > > > > >On Tuesday 29 July 2003 07:34 pm, Joel Rosi-Schwartz wrote: > > >>I have read through much of the mail list in the past few days to > > catch > > > >>up on the state of affairs. I have come across several threads that > > >>indicate problems with database corruption. The threads seem to > > point to > > > >>locking issues, threading issues and caching/flushing issues. Are > > these > > > >>still issues or have they been addressed? The threads seem to > > dangle > > > >>without concrete resolution. > > >> > > >>What I am really trying to ascertain is whether eXist is ready yet for > > >>use in a production system where it is has many simultaneous > > readers and > > > >>writers, and where it is expected to survive a system crash without > > data > > > >>corruption. Data loss during a crash is to be expected and thus > > >>tolerated, but loss of the data store would be unacceptable. > > > > > >------------------------------------------------------- > > >This SF.Net email sponsored by: Free pre-built ASP.NET sites > > including > > > >Data Reports, E-commerce, Portals, and Forums are available now. > > >Download today and enter to win an XBOX or Visual Studio .NET. > > > >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/0 > >1 > > > > >_______________________________________________ > > >Exist-open mailing list > > >Exi...@li... > > >https://lists.sourceforge.net/lists/listinfo/exist-open |
From: Per N. <per...@re...> - 2003-08-04 07:26:24
|
On Sunday 03 August 2003 17.08, Joel Rosi-Schwartz wrote: >... > I have created eXist and xmlDb services in JBoss. Basically this is > created using the MBean code in third party with some modifications by > Kevin O'Neill and some more by myself. The services run quite well. > >... How do you think that the MBeans could be improved? Would you mind sharing the modifications you've done to the services? Best regards, Per |
From: Joel Rosi-S. <Joel.Rosi-Schwartz@Etish.org> - 2003-08-04 08:59:20
|
Per Nyfelt wrote: >On Sunday 03 August 2003 17.08, Joel Rosi-Schwartz wrote: > > >>... >>I have created eXist and xmlDb services in JBoss. Basically this is >>created using the MBean code in third party with some modifications by >>Kevin O'Neill and some more by myself. The services run quite well. >> >>... >> >> > >How do you think that the MBeans could be improved? Would you mind sharing the >modifications you've done to the services? > First, I need to say that I have plagiarized from so many quarters, that I really no longer remember what is my contribution and what is stolen. No claims of authorship or originality are expressed or implied ;-) I am working with both Xindice and eXist. My hope was to abstract the differences between the implementation details in the service layer so that applications could swap them in and out transparently. You already started down this path when you spilt the MBeans between eXist, Xindice and xmlDb, I am just trying to take it a bit further so that they are a bit more rationalized. In fact I am on the path of factoring out as much as I can into a super class, so that all of my mbeans have a common parent that handles services such as defining their home and setting up JNDI and also a common parent to all of my data related mbeans to factor out their common features, e.g. datadir. I have this working now, but I only use eXist and Xindice for datastore at the moment. I do not yet rely on querying the database or using Xupdate. From a conversation that I had with Kevin O'Neill I learned that there were some implementation differences between the database that made my goal of transparent swapping difficult to achieve, quote Kevin: This was my inital plan. Unfortunatly they handle things like Collection.getName() differently (xindice returns the local name, exist returns the full path). Also eXist returns nodes from queries, xindice returns documents (though these are easily broken). I would be interested in knowing what other gotchas exist? I any case my plan at the moment is to take it as far as I reasonably can. I have about three more months until I publicly beta my application. Before doing so I plan on building a stress tester to put my application under varying degrees of load to measure stability, robustness, aliveness, etc. I figure this will also flush a bug or two ;-) I want to run these against both eXist and Xindice to help me make a final decision on which one I will be packaging, As far as sharing the changes to the services, I am very happily to, but I have a serious time problem at the moment. Per, if you have some time to help, I would be happy to zip up my service sources as they stand for you to take a look at. Possibly you would be willing to take out what you think is useful and refractor it into your release. - joel |
From: Per N. <per...@re...> - 2003-08-04 09:47:43
|
On Monday 04 August 2003 10.59, Joel Rosi-Schwartz wrote: ... > As far as sharing the changes to the services, I am very happily to, but > I have a serious time problem at the moment. Per, if you have some time > to help, I would be happy to zip up my service sources as they stand for > you to take a look at. Possibly you would be willing to take out what > you think is useful and refractor it into your release. > > - joel Yes that's fine, I'd be happy to take a look at what you have... Best regards, Per |