[jira] Updated: (JCR-1673) Date comparitons are backwards in Queries
[ https://issues.apache.org/jira/browse/JCR-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Neale updated JCR-1673: --- Affects Version/s: core 1.4.4 > Date comparitons are backwards in Queries > - > > Key: JCR-1673 > URL: https://issues.apache.org/jira/browse/JCR-1673 > Project: Jackrabbit > Issue Type: Bug > Components: query >Affects Versions: core 1.4.1, core 1.4.4 >Reporter: Michael Neale >Priority: Critical > > Imagine there is a node with jcr:created of: > 2008-07-08T15:10:07.125+10:00 > The following query: > SELECT ... FROM WHERE jcr:created < '2009-07-08T15:10:07.125+10:00' > should return it, but it doesn't. However, if you put: > SELECT ... FROM WHERE jcr:created > '2009-07-08T15:10:07.125+10:00' > then it does return it. Whoops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] Adding event interface to jackrabbit api
Jukka Zitting wrote: Clustering should generally be transparent to client applications, so I'm a bit concerned about adding functionality like this. Yes, in general it should be transparent. What's the use case? The most relevant use case I can come up with is a case where multiple copies of the "same" event listener is registered for a (clustered) repository by multiple (clustered) instances of a client application. Then it would be nice if an event would be handled by only one instead of all of those listeners. Yes, that's exactly the use case - and the use cases I know of always do post processing of data. Instead of making this coordination a task for the listeners (checking of the proposed isLocal() flag), how about if we pushed that responsibility to the repository? If, during registration, an event listener could be marked as a part of a special clustered set of listeners, then the repository could make sure that a matching event is only delivered to a single listener in that set. The nice thing about this is that as a general solution it doesn't even need to be clustering-related, it would work equally well for a single server that may serve multiple copies of the same client. I'm not sure which solution is the "nicer" one :) Both solutions work in each scenario. The fact is that today people cast the event to EventImpl and use this method. That's where I got the idea from. Doing that in the general case might be a bit tricky, but a simpler version of the same idea would be for example to define a LocalOnlyEventListener extension interface for event listeners that should only be notified of locally (on the same cluster node) initiated changes. Works for me as well. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (JCR-1672) Adding Event interface and isLocal()
[ https://issues.apache.org/jira/browse/JCR-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611462#action_12611462 ] Carsten Ziegeler commented on JCR-1672: --- Yes, makes sense. > Adding Event interface and isLocal() > > > Key: JCR-1672 > URL: https://issues.apache.org/jira/browse/JCR-1672 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-api >Affects Versions: 1.4 >Reporter: Carsten Ziegeler > > when a repository cluster is used, it seems that a common problem many people > have is to detect if an observation event is send because of changes on the > local instance or a remote instance of the cluster. > This is especially important if you want to do post processing of data > based on observation (the post processing should only be done by one instance > in the cluster). > A current solution is to cast the jcr event object to the EventImpl of > jackrabbit core which is obviously not a nice solution :) > So what about adding an event interface to jackrabbit api which extends the > jcr event interface and adds the isLocal() method? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1673) Date comparitons are backwards in Queries
[ https://issues.apache.org/jira/browse/JCR-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611458#action_12611458 ] Michael Neale commented on JCR-1673: Exactly the same occurs with XPath. I have a feeling I must be stupid and that I am seriously being silly, at least I hope that is the case. > Date comparitons are backwards in Queries > - > > Key: JCR-1673 > URL: https://issues.apache.org/jira/browse/JCR-1673 > Project: Jackrabbit > Issue Type: Bug > Components: query >Affects Versions: core 1.4.1 >Reporter: Michael Neale >Priority: Critical > > Imagine there is a node with jcr:created of: > 2008-07-08T15:10:07.125+10:00 > The following query: > SELECT ... FROM WHERE jcr:created < '2009-07-08T15:10:07.125+10:00' > should return it, but it doesn't. However, if you put: > SELECT ... FROM WHERE jcr:created > '2009-07-08T15:10:07.125+10:00' > then it does return it. Whoops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1673) Date comparitons are backwards in Queries
[ https://issues.apache.org/jira/browse/JCR-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Neale updated JCR-1673: --- Description: Imagine there is a node with jcr:created of: 2008-07-08T15:10:07.125+10:00 The following query: SELECT ... FROM WHERE jcr:created < '2009-07-08T15:10:07.125+10:00' should return it, but it doesn't. However, if you put: SELECT ... FROM WHERE jcr:created > '2009-07-08T15:10:07.125+10:00' then it does return it. Whoops. was: Imagine there is a node with jcr:created of: 2008-07-08T15:10:07.125+10:00 The following query: SELECT ... FROM WHERE jcr:created < '2008-07-09T14:55:29.774+10:00' should return it, but it doesn't. However, if you put: SELECT ... FROM WHERE jcr:created > '2008-07-09T14:55:29.774+10:00' then it does return it. Whoops. Summary: Date comparitons are backwards in Queries (was: Date comparitons are backwards in SQL query) > Date comparitons are backwards in Queries > - > > Key: JCR-1673 > URL: https://issues.apache.org/jira/browse/JCR-1673 > Project: Jackrabbit > Issue Type: Bug > Components: query >Affects Versions: core 1.4.1 >Reporter: Michael Neale >Priority: Critical > > Imagine there is a node with jcr:created of: > 2008-07-08T15:10:07.125+10:00 > The following query: > SELECT ... FROM WHERE jcr:created < '2009-07-08T15:10:07.125+10:00' > should return it, but it doesn't. However, if you put: > SELECT ... FROM WHERE jcr:created > '2009-07-08T15:10:07.125+10:00' > then it does return it. Whoops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1673) Date comparitons are backwards in SQL query
Date comparitons are backwards in SQL query --- Key: JCR-1673 URL: https://issues.apache.org/jira/browse/JCR-1673 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: core 1.4.1 Reporter: Michael Neale Priority: Critical Imagine there is a node with jcr:created of: 2008-07-08T15:10:07.125+10:00 The following query: SELECT ... FROM WHERE jcr:created < '2008-07-09T14:55:29.774+10:00' should return it, but it doesn't. However, if you put: SELECT ... FROM WHERE jcr:created > '2008-07-09T14:55:29.774+10:00' then it does return it. Whoops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] Adding event interface to jackrabbit api
Hi, On Thu, Jul 3, 2008 at 4:07 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > when a repository cluster is used, it seems that a common problem many > people have is to detect if an observation event is send because of changes > on the local instance or a remote instance of the cluster. Clustering should generally be transparent to client applications, so I'm a bit concerned about adding functionality like this. What's the use case? The most relevant use case I can come up with is a case where multiple copies of the "same" event listener is registered for a (clustered) repository by multiple (clustered) instances of a client application. Then it would be nice if an event would be handled by only one instead of all of those listeners. Instead of making this coordination a task for the listeners (checking of the proposed isLocal() flag), how about if we pushed that responsibility to the repository? If, during registration, an event listener could be marked as a part of a special clustered set of listeners, then the repository could make sure that a matching event is only delivered to a single listener in that set. The nice thing about this is that as a general solution it doesn't even need to be clustering-related, it would work equally well for a single server that may serve multiple copies of the same client. Doing that in the general case might be a bit tricky, but a simpler version of the same idea would be for example to define a LocalOnlyEventListener extension interface for event listeners that should only be notified of locally (on the same cluster node) initiated changes. BR, Jukka Zitting
[jira] Commented: (JCR-1672) Adding Event interface and isLocal()
[ https://issues.apache.org/jira/browse/JCR-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611362#action_12611362 ] Tobias Bocanegra commented on JCR-1672: --- i would rather add the isExternal() method to the interface. 'local' is already occupied by the listener registration and means that only local-events (i.e. this session) should be observed. > Adding Event interface and isLocal() > > > Key: JCR-1672 > URL: https://issues.apache.org/jira/browse/JCR-1672 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-api >Affects Versions: 1.4 >Reporter: Carsten Ziegeler > > when a repository cluster is used, it seems that a common problem many people > have is to detect if an observation event is send because of changes on the > local instance or a remote instance of the cluster. > This is especially important if you want to do post processing of data > based on observation (the post processing should only be done by one instance > in the cluster). > A current solution is to cast the jcr event object to the EventImpl of > jackrabbit core which is obviously not a nice solution :) > So what about adding an event interface to jackrabbit api which extends the > jcr event interface and adds the isLocal() method? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1672) Adding Event interface and isLocal()
Adding Event interface and isLocal() Key: JCR-1672 URL: https://issues.apache.org/jira/browse/JCR-1672 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-api Affects Versions: 1.4 Reporter: Carsten Ziegeler when a repository cluster is used, it seems that a common problem many people have is to detect if an observation event is send because of changes on the local instance or a remote instance of the cluster. This is especially important if you want to do post processing of data based on observation (the post processing should only be done by one instance in the cluster). A current solution is to cast the jcr event object to the EventImpl of jackrabbit core which is obviously not a nice solution :) So what about adding an event interface to jackrabbit api which extends the jcr event interface and adds the isLocal() method? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1671) Support for external datasources with transactions in 1.3.1
Support for external datasources with transactions in 1.3.1 --- Key: JCR-1671 URL: https://issues.apache.org/jira/browse/JCR-1671 Project: Jackrabbit Issue Type: Wish Components: transactions Affects Versions: 1.3.1 Environment: Websphere application server 6.0, DB2 database Reporter: Badal Priority: Critical Fix For: 1.3.1 Jackrabbit 1.3.1 should support transactions with external datasources -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1629) SPI: Testsuite for the SPI Interfaces
[ https://issues.apache.org/jira/browse/JCR-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1629: Attachment: JCR-1629_spi2jcr.diff > SPI: Testsuite for the SPI Interfaces > - > > Key: JCR-1629 > URL: https://issues.apache.org/jira/browse/JCR-1629 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-spi >Reporter: angela > Attachments: JCR-1629.diff, JCR-1629_jcr2spi.diff, > JCR-1629_spi2jcr.diff > > > now that people start writing SPI implementations we should provide a > test-suite that runs on the SPI directly in order to provide the developers a > way to assert basic compliance of their implementation without having the JCR > api in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1629) SPI: Testsuite for the SPI Interfaces
[ https://issues.apache.org/jira/browse/JCR-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1629: Attachment: JCR-1629_jcr2spi.diff > SPI: Testsuite for the SPI Interfaces > - > > Key: JCR-1629 > URL: https://issues.apache.org/jira/browse/JCR-1629 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-spi >Reporter: angela > Attachments: JCR-1629.diff, JCR-1629_jcr2spi.diff, > JCR-1629_spi2jcr.diff > > > now that people start writing SPI implementations we should provide a > test-suite that runs on the SPI directly in order to provide the developers a > way to assert basic compliance of their implementation without having the JCR > api in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1629) SPI: Testsuite for the SPI Interfaces
[ https://issues.apache.org/jira/browse/JCR-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1629: Attachment: JCR-1629.diff > SPI: Testsuite for the SPI Interfaces > - > > Key: JCR-1629 > URL: https://issues.apache.org/jira/browse/JCR-1629 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-spi >Reporter: angela > Attachments: JCR-1629.diff > > > now that people start writing SPI implementations we should provide a > test-suite that runs on the SPI directly in order to provide the developers a > way to assert basic compliance of their implementation without having the JCR > api in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1629) SPI: Testsuite for the SPI Interfaces
[ https://issues.apache.org/jira/browse/JCR-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611180#action_12611180 ] angela commented on JCR-1629: - > Using the jackrabbit-jcr2spi test for a specific spi implementation is > problematic since it has dependencies on the > existing spi implementations (i.e. spi2jcr). What we need here is a way to > run the jackrabbit-jcr2spi tests for an arbitrary > spi implementation without introducing alien dependencies. agreed. but this is yet another issue or at least an extension to the original goal of this issue. anyway. i will attach patches that attempt to provide - basic setup that allows to write tests against the SPI interfaces (located in the jackrabbit-spi project) - clean jcr2spi from dependency to jackrabbit-spi2jcr and jackrabbit-core - add test-jar goal for both > jackrabbit-jcr2spi and > jackrabbit-spi - jackrabbit-spi2jcr: run jcr2spi-tests and spi-tests by adding extra dependencies with the 'tests' classifier. it worked for me (this time)... but i'm not totally convinced that this part of the maven functionality really works reliably. please comment angela > SPI: Testsuite for the SPI Interfaces > - > > Key: JCR-1629 > URL: https://issues.apache.org/jira/browse/JCR-1629 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-spi >Reporter: angela > Attachments: JCR-1629.diff > > > now that people start writing SPI implementations we should provide a > test-suite that runs on the SPI directly in order to provide the developers a > way to assert basic compliance of their implementation without having the JCR > api in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster
[ https://issues.apache.org/jira/browse/JCR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611172#action_12611172 ] Brett Connor commented on JCR-1670: --- I looked at JCR-1440, I thought this use case was simpler. It may be the same underlying cause, whatever that is, but I couldn' tell. My first guess is the cluster code updates are not synchronized so there are incomplete / non-visible memory writes. In that vein I should say that I'm running on sun hotspot 1.5.2_02. > NPE when clustered JR queries version history on a node that has just had a > version added by another JR in the same cluster > --- > > Key: JCR-1670 > URL: https://issues.apache.org/jira/browse/JCR-1670 > Project: Jackrabbit > Issue Type: Bug > Components: clustering >Affects Versions: core 1.4.3 > Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft > SQL 2005 bundled persistence manager, datastore. >Reporter: Brett Connor >Priority: Critical > > Two computers A and B running jboss webapp, including in-process Jackrabbit > instances in a cluster. > - A checks out a versioned node, then checks it in and unlocks it > - A notifies B (through a non JR mechanism) that the node has been updated > - B finds the node (by UUID) and calls getVersionHistory().getAllVersions() > This results in java.lang.NullPointerException > at > org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147) > at org.apache.jackrabbit.core.version.VersionIteratorImpl. > (VersionIteratorImpl.java:68) > at > org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95) > The addVersion() method is synchronized, but looks like it's reading a null > from 'successors'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster
[ https://issues.apache.org/jira/browse/JCR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611170#action_12611170 ] Micah Whitacre commented on JCR-1670: - The stack trace and use case seems similar to JCR-1440. > NPE when clustered JR queries version history on a node that has just had a > version added by another JR in the same cluster > --- > > Key: JCR-1670 > URL: https://issues.apache.org/jira/browse/JCR-1670 > Project: Jackrabbit > Issue Type: Bug > Components: clustering >Affects Versions: core 1.4.3 > Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft > SQL 2005 bundled persistence manager, datastore. >Reporter: Brett Connor >Priority: Critical > > Two computers A and B running jboss webapp, including in-process Jackrabbit > instances in a cluster. > - A checks out a versioned node, then checks it in and unlocks it > - A notifies B (through a non JR mechanism) that the node has been updated > - B finds the node (by UUID) and calls getVersionHistory().getAllVersions() > This results in java.lang.NullPointerException > at > org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147) > at org.apache.jackrabbit.core.version.VersionIteratorImpl. > (VersionIteratorImpl.java:68) > at > org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95) > The addVersion() method is synchronized, but looks like it's reading a null > from 'successors'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1658) Executing query throws UnsupportedRepositoryOperationException(LEVEL_2_SUPPORTED) for a level 1 only implementation
[ https://issues.apache.org/jira/browse/JCR-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1658. --- Resolution: Fixed Fix Version/s: 1.5 Fixed in revision: 674491 Thank you for reporting this issue. > Executing query throws > UnsupportedRepositoryOperationException(LEVEL_2_SUPPORTED) for a level 1 only > implementation > > > Key: JCR-1658 > URL: https://issues.apache.org/jira/browse/JCR-1658 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-jcr2spi >Reporter: Michael Dürig > Fix For: 1.5 > > > Executing a query throws > UnsupportedRepositoryOperationException(LEVEL_2_SUPPORTED) it the spi > implementation is not level 2. This is because > org.apache.jackrabbit.jcr2spi.query.execute() calls session.getValueFactory() > which - by contract - throws if level 2 is not supported. A quick fix would > be to call getJcrValueFactory() (available from the ManagerProvider interface > implemented by SessionImpl) instead of getValueFactory(). However, I think a > better fix might be to pass the ManagerProvider to the QueryImpl constructor > instead of the session, all the managers and providers separately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Repository locked by one server in clustered mode
On Mon, Jul 7, 2008 at 9:14 AM, Balak Dev <[EMAIL PROTECTED]> wrote: > > Hi Alex and Thomas, > > Thanks a lot for your help. We were able to get the clustered configuration > going. > > I have few more doubts on the architecture part. We have the configuration > in such a way that everything is being pointed to the database. I mean the > Filesystem, persistance manager of the workspace, versioning and also search > index of the workspace and the cluster configuration. For a clustered environment you should (must) have the index on the local disk and not shared inside the database. Using the LocalFileSystem as FileSystem and a BundlePersistenceManager (for the specific DB) as PersistenceManager is the standard way to go. > If i look at my workspace, i have the workspace configuration file and a > folder called index. I guess the index is for the search part. Yes, if you have a SearchIndex configuration (which you probably want in all cases, cause it is needed for searching the repository), the only available implementation is lucene-based, which stores its files in the subfolder index/ of the workspace. > 1) I didnt understand where the actual data is being stored? The persistence manager takes care of storing the actual data. If you use a database pm, it will store the data in a few tables in the db - depending on the pm implementation. The recommended bundle persistence managers store bundles (1 bundle = 1 node + its properties) per row + a other tables for references etc. > 2) what is the role of Filesystem configuration? To store things that work on a file system style, eg. workspace.xml and lucene index files. It is recommended to use the standard LocalFileSystem, which stores everything inside the normal file system, if there is not a specific reason to do otherwise. > > 3) what is the role of workspace when we are having the configuartions > pointing to database? A workspace is a JCR concept. One repository can have multiple workspaces, each having it's own node tree. See the JCR spec for more. Please note that if you change the repository.xml, especially the element, it will only affect new workspaces you create - because it acts just as a template. If you have existing workspaces, you must change the workspace.xml inside workspaces/ (the latter path is given by the element in the repository.xml - but you should not change the default setting if there is no specific reason to do so). Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
[jira] Created: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster
NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster --- Key: JCR-1670 URL: https://issues.apache.org/jira/browse/JCR-1670 Project: Jackrabbit Issue Type: Bug Components: clustering Affects Versions: core 1.4.3 Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft SQL 2005 bundled persistence manager, datastore. Reporter: Brett Connor Priority: Critical Two computers A and B running jboss webapp, including in-process Jackrabbit instances in a cluster. - A checks out a versioned node, then checks it in and unlocks it - A notifies B (through a non JR mechanism) that the node has been updated - B finds the node (by UUID) and calls getVersionHistory().getAllVersions() This results in java.lang.NullPointerException at org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147) at org.apache.jackrabbit.core.version.VersionIteratorImpl. (VersionIteratorImpl.java:68) at org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95) The addVersion() method is synchronized, but looks like it's reading a null from 'successors'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1573) Lucene Query Exception: 'attempt to access a deleted document'
[ https://issues.apache.org/jira/browse/JCR-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610920#action_12610920 ] David McKitterick commented on JCR-1573: My initial thought was that it did not have a positive affect but perhaps you are right that this issue was resolved with the Lucene version change to 2.2.0. I'll let you know if I have any other similar problems. Many thanks, David. > Lucene Query Exception: 'attempt to access a deleted document' > -- > > Key: JCR-1573 > URL: https://issues.apache.org/jira/browse/JCR-1573 > Project: Jackrabbit > Issue Type: Bug > Components: query >Affects Versions: core 1.4.2 > Environment: Windows XP, PostgreSQL database, Spring, Tomcat >Reporter: David McKitterick > Attachments: jackrabbit-repo.xml > > > Hi, > I am getting an exception when trying to execute a query through the (Spring) > JcrTemplate classusing the following code: > QueryManager qMgr = session.getWorkspace().getQueryManager(); > QueryResult result = qMgr.createQuery(xpathQuery, Query.XPATH ).execute(); > The exception is thrown at the second line and is as follows: > [DEBUG] << "[0x9]at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Hits.getMoreDocs(Hits.java:74)[\n]" > [DEBUG] << "[0x9]at org.apache.lucene.search.Hits.(Hits.java:53)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Searcher.search(Searcher.java:46)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Searcher.search(Searcher.java:38)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.SearchIndex.executeQuery(SearchIndex.java:660)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl.executeQuery(QueryResultImpl.java:242)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl.getResults(QueryResultImpl.java:290)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl. (QueryResultImpl.java:192)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:138)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java:176)[\n]" > [DEBUG] << "[0x9]at > com.intel.cds.cr.jcr.JcrManager$5.doInJcr(JcrManager.java:363)[\n]" > [DEBUG] << "[0x9]at > org.springmodules.jcr.JcrTemplate.execute(JcrTemplate.java:76)[\n]" > [DEBUG] << "[0x9]at > org.springmodules.jcr.JcrTemplate.execute(JcrTemplate.java:108)[\n]" > [DEBUG] << "[0x9]... 19 more[\n]" > [DEBUG] << > "" > org.apache.axis2.AxisFault: attempt to access a deleted document > at > org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486) > at > org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343) > at > org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389) > at > org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211) > at > org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) > My Jackrabbit/Lucene configuration is as follows: > > > > > > > > > Is this a configuration issue or a bug? > Thanks, > David. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1573) Lucene Query Exception: 'attempt to access a deleted document'
[ https://issues.apache.org/jira/browse/JCR-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610915#action_12610915 ] Marcel Reutegger commented on JCR-1573: --- > node.update(session.getWorkspace().getName()); if that node is in the workspace which is returned by session.getWorkspace().getName() then this is actually a no-op. There must be something else you changed, which made the indexing work again correctly. Are you sure that reverting back to Lucene 2.2 did not resolve the issue? You probably also have to re-index your workspaces because Lucene is not able to read index files from a newer version. > Lucene Query Exception: 'attempt to access a deleted document' > -- > > Key: JCR-1573 > URL: https://issues.apache.org/jira/browse/JCR-1573 > Project: Jackrabbit > Issue Type: Bug > Components: query >Affects Versions: core 1.4.2 > Environment: Windows XP, PostgreSQL database, Spring, Tomcat >Reporter: David McKitterick > Attachments: jackrabbit-repo.xml > > > Hi, > I am getting an exception when trying to execute a query through the (Spring) > JcrTemplate classusing the following code: > QueryManager qMgr = session.getWorkspace().getQueryManager(); > QueryResult result = qMgr.createQuery(xpathQuery, Query.XPATH ).execute(); > The exception is thrown at the second line and is as follows: > [DEBUG] << "[0x9]at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Hits.getMoreDocs(Hits.java:74)[\n]" > [DEBUG] << "[0x9]at org.apache.lucene.search.Hits.(Hits.java:53)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Searcher.search(Searcher.java:46)[\n]" > [DEBUG] << "[0x9]at > org.apache.lucene.search.Searcher.search(Searcher.java:38)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.SearchIndex.executeQuery(SearchIndex.java:660)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl.executeQuery(QueryResultImpl.java:242)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl.getResults(QueryResultImpl.java:290)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryResultImpl. (QueryResultImpl.java:192)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.lucene.QueryImpl.execute(QueryImpl.java:138)[\n]" > [DEBUG] << "[0x9]at > org.apache.jackrabbit.core.query.QueryImpl.execute(QueryImpl.java:176)[\n]" > [DEBUG] << "[0x9]at > com.intel.cds.cr.jcr.JcrManager$5.doInJcr(JcrManager.java:363)[\n]" > [DEBUG] << "[0x9]at > org.springmodules.jcr.JcrTemplate.execute(JcrTemplate.java:76)[\n]" > [DEBUG] << "[0x9]at > org.springmodules.jcr.JcrTemplate.execute(JcrTemplate.java:108)[\n]" > [DEBUG] << "[0x9]... 19 more[\n]" > [DEBUG] << > "" > org.apache.axis2.AxisFault: attempt to access a deleted document > at > org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486) > at > org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343) > at > org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389) > at > org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211) > at > org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) > My Jackrabbit/Lucene configuration is as follows: > > > > > > > > > Is this a configuration issue or a bug? > Thanks, > David. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Repository locked by one server in clustered mode
Hi Alex and Thomas,
Thanks a lot for your help. We were able to get the clustered configuration
going.
I have few more doubts on the architecture part. We have the configuration
in such a way that everything is being pointed to the database. I mean the
Filesystem, persistance manager of the workspace, versioning and also search
index of the workspace and the cluster configuration.
If i look at my workspace, i have the workspace configuration file and a
folder called index. I guess the index is for the search part.
1) I didnt understand where the actual data is being stored?
2) what is the role of Filesystem configuration?
3) what is the role of workspace when we are having the configuartions
pointing to database?
Thanks,
Bala.
Alexander Klimetschek wrote:
>
> On Mon, Jun 30, 2008 at 6:44 AM, Balak Dev <[EMAIL PROTECTED]> wrote:
>> We are actually using JBoss DROOLS, which internally uses Jack rabbit.
>>
>> We have both of our managed servers [nodes] running on a single machine
>> in a
>> single domain.
>>
>> I have few more questions here:
>>
>> a) The repository cannot be shared. So does it mean that i need to have a
>> seperate repository folder get created for each of the managed servers
>> [nodes]. If yes, then where is that i need to mention about it.
>
> Yes. You need a database persistence manager that is transactional,
> which actually shares the data (see bottom of
> http://wiki.apache.org/jackrabbit/Clustering). The FileSystem's can be
> normal LocalFileSystem, because each node will store the separately.
> You need a different repository home for each cluster node, including
> a repository.xml that is typically the same except for the cluster id.
> Usage of ${rep.home} and ${wsp.home} will give the FileSystems
> different locations for each node and the PM configuration pointing to
> a database will point to the database as the shared location for the
> data.
>
>>
>> b) Or is it that i can have a single repository folder, but have
>> different
>> cluster configurations.
>>
>> eg:-
>> ..
>>
>>
>>
>> ..
>>and so on...
>>
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> [EMAIL PROTECTED]
>
>
--
View this message in context:
http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18311243.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
