headers
mmjose26 | 1 Jul 2011 21:47
Picon
Favicon

Error in WebDav clients using clustered WebDav server.

Hi !

I'm trying to configure jackrabbit in a clustered environment.
(following the clustered configuration guide wiki)
each node has the following in a single ear:

Jackrabbit deployed in OC4J as JCA, this expose the repository by JNDI and works with JTA transactions.
JackRabbit WebApp, this enable the repository by WebDav to remote clients.
Business App, consuming the repository by JNDI and enabling JTA transactions.
I'm using spring modules for integrate jcr with Business App and with remote clients.

All works fine in single node, but, in cluster, ONLY for the remote clients, 
I have some exceptions when I try to saving and versioning a node:

it happen when I try to get the identifier of a new saved node:

                        Node content  =
saveFile(resource,session);//set the properties and add node to repo
                        String path = content.getPath();
                        session.save();
                        String id = content.getIdentifier();// this
throws javax.jcr.InvalidItemStateException
                        //'org.apache.jackrabbit.jcr2spi.NodeImpl <at> 2bace2'
doesn't exist anymore. (Status = REMOVED)
                        session.getWorkspace().getVersionManager().checkin(path);
                        return id;

if I try to obtain the saved node again, the exception change:
                        Node content  = saveFile(resource,session);//set the
properties and add node to repo
(Continue reading)

Permalink | Reply | 0 comments |
headers
ChadDavis | 5 Jul 2011 01:03
Picon

batch read depth

I'm tuning the performance of my spi/davex remoting, and I'm a bit
unclear about the batch read depth.  What are the units of depth?  Is
it an "item"?  In other words, if I get a node X, do I need a batch
depth of 1 to also retrieve the properties of node X.  Or would a
depth of 1 read all of X's child nodes?

Also, does the depth always start from the node being returned by
node.getNode()?  Or is it relative to the root node of the repo?
Permalink | Reply | 1 comment |
headers
ChadDavis | 5 Jul 2011 21:33
Picon

Clustered Deployment versus Davex Remoting

Our product currently is in beta and uses the Davex remoting style
deployment.  We are addressing some performance issues we are
experiencing with this deployment.  I'm documenting those issues in
other threads on this list.  None of them seem insurmountable for us
-- in other words, I'm not saying that I think the davex stack is bad.

However, we plan to move to the clustered deployment in the future.
My question is whether we should perhaps move to the clustered
deployment now, rather than spending time working on the performance
of the davex stack.  I have the sense that the clustered deployment
may be the more well traveled deployment path, and that might mean
that more folks have done performance work on it.

So, does anyone have a sense of whether the clustered deployment is
actually more widely adopted than the davex remoting?   I want to try
to determine the most used deployment model in order to leverage the
efforts of the community better.
Permalink | Reply | 1 comment |
headers
Jack Kirsten | 5 Jul 2011 21:34
Picon
Favicon

Strange XPath Issue

Hi, I'm relatively new to Jackrabbit.  In our application we never turned on
SearchIndex section within repository.xml (so as workspace.xml) files
because we always go directly to a given document using the JCR UUID
reference.  By the way we use *Jackrabbit v2.2.1* and *Oracle* as the
repository. Now our requirements are getting expanded as we would like to
use the document metadata feature to store contextual info about a document
so that we can use the metadata to retrieve a selected set of documents.

As the first step, I added the default SearchIndex section in workspace.xml
file and restarted the JCR.

I saw a bunch of lines like this in my log file - then I saw it created the
*index* folder under workspace area.

*2011-07-05 15:04:01.724 INFO  [WebContainer : 0] MultiIndex.java:1204 
indexing...
/vfs:metaData/21ee130e-978e-415f-bfd1-7aa03d91608c/vfs:attributes (3500)*

I have the folder structure like this.  When I create a document in JCR, I
specify the metadata info as part of the document which is by a complex XSD
type with tags like docType, uploadedBy, contextValue, etc.

/ (root)
  /MyApp (sub-folder)
      /documents/ (sub-folder)
         /document-1.pdf (file)
         /document-2.pdf (file)
     /accounts/ (sub-folder)
         /account.txt (file)
        etc...
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeroen Reijn | 5 Jul 2011 22:25

Re: Strange XPath Issue

Hi Jack,

see my comments inline.

On Tue, Jul 5, 2011 at 9:34 PM, Jack Kirsten <jkfriends <at> hotmail.com> wrote:
> Hi, I'm relatively new to Jackrabbit.  In our application we never turned on
> SearchIndex section within repository.xml (so as workspace.xml) files
> because we always go directly to a given document using the JCR UUID
> reference.  By the way we use *Jackrabbit v2.2.1* and *Oracle* as the
> repository. Now our requirements are getting expanded as we would like to
> use the document metadata feature to store contextual info about a document
> so that we can use the metadata to retrieve a selected set of documents.
>
> As the first step, I added the default SearchIndex section in workspace.xml
> file and restarted the JCR.
>
> I saw a bunch of lines like this in my log file - then I saw it created the
> *index* folder under workspace area.
>
> *2011-07-05 15:04:01.724 INFO  [WebContainer : 0] MultiIndex.java:1204
> indexing...
> /vfs:metaData/21ee130e-978e-415f-bfd1-7aa03d91608c/vfs:attributes (3500)*
>
> I have the folder structure like this.  When I create a document in JCR, I
> specify the metadata info as part of the document which is by a complex XSD
> type with tags like docType, uploadedBy, contextValue, etc.
>
> / (root)
>  /MyApp (sub-folder)
>      /documents/ (sub-folder)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jack Kirsten | 5 Jul 2011 22:31
Picon
Favicon

Re: Strange XPath Issue

Thanks for your reply Jeroen, I just tried this query as you suggested:

*MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*

But still the same effect - no documents found. 

--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3647040.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Permalink | Reply | 5 comments |
headers
Alexander Klimetschek | 6 Jul 2011 00:07
Picon
Favicon
Gravatar

Re: Strange XPath Issue

On 05.07.11 22:31, "Jack Kirsten" <jkfriends <at> hotmail.com> wrote:

>Thanks for your reply Jeroen, I just tried this query as you suggested:
>
>*MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*

If you start with an absolute path (e.g. not //*), it needs to start with
"/jcr:root":

/jcr:root/MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_D
OCS']

This is because of the implicit mapping onto the xml document view of the
repository, which requires to add an explicit xml element for the root
node called "jcr:root" [0]. See also [1].

[0] http://www.day.com/specs/jcr/1.0/6.4.2.2_Workspace_Root.html
[1] http://www.day.com/specs/jcr/1.0/6.6.3.4_Path_Constraint.html

Regards,
Alex

--

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Permalink | Reply | 4 comments |
headers
Jukka Zitting | 6 Jul 2011 07:52
Picon
Gravatar

Re: Clustered Deployment versus Davex Remoting

Hi,

On Tue, Jul 5, 2011 at 9:33 PM, ChadDavis <chadmichaeldavis <at> gmail.com> wrote:
> So, does anyone have a sense of whether the clustered deployment is
> actually more widely adopted than the davex remoting?   I want to try
> to determine the most used deployment model in order to leverage the
> efforts of the community better.

If you have a read-balanced set of frontend servers that all access
the repository (like a typical cluster of web servers), then a
clustered Jackrabbit setup is preferred over accessing the repository
remotely. A cluster performs better than remote connections to a
central server in practically all cases.

BR,

Jukka Zitting
Permalink | Reply | 0 comments |
headers
Stefan Guggisberg | 6 Jul 2011 09:38
Picon

Re: batch read depth

On Tue, Jul 5, 2011 at 1:03 AM, ChadDavis <chadmichaeldavis <at> gmail.com> wrote:
> I'm tuning the performance of my spi/davex remoting, and I'm a bit
> unclear about the batch read depth.  What are the units of depth?  Is
> it an "item"?  In other words, if I get a node X, do I need a batch
> depth of 1 to also retrieve the properties of node X.  Or would a
> depth of 1 read all of X's child nodes?

0: returns specified node incl. properties and child node names (empty objects)
1: returns specified node incl. properties and child nodes (props and
grand child names)
n: and so forth...
-1: returns entire subtree

>
> Also, does the depth always start from the node being returned by
> node.getNode()?

yes

> Or is it relative to the root node of the repo?
>

you'll find more information here:
http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/server/remoting/davex/JcrRemotingServlet.html

cheers
stefan
Permalink | Reply | 0 comments |
headers
juanillototal | 7 Jul 2011 11:53
Picon

Query error when using 'OR' in the 'WHERE' part of the query.

Hi All There

My name is Juan and I'm developing a web application (JSP) over jackrabbit.
I have jackrabbit running OK.
I've made a new custom type called mmns:Asset which is child of nt:file.
This type has a property called 'tags' where I put some tags to look for.
I'm able to upload files and set the type of those files to mmsn:Asset.
But when I'm searching the repository, using Query.JCR_SQL2 I get an issue:

If the query is:
SELECT * FROM [mmns:Asset] As asset WHERE (NAME(asset) LIKE $searchName)
it works fine, and I get some results.

If query is:
SELECT * FROM [mmns:Asset] As asset WHERE ([mmns:tags] LIKE $searchTags)
it works fine aswell, and I get some results.

If I have this query:
SELECT * FROM [mmns:Asset] As asset WHERE (NAME(asset) LIKE $searchName) AND
([mmns:tags] LIKE $searchTags)
It works fine and I get the results.

BUT the problem comes when I try to search using 'OR' command in the WHERE
clause
SELECT * FROM [mmns:Asset] As asset WHERE (NAME(asset) LIKE $searchName) OR
([mmns:tags] LIKE $searchTags)
Then I get an error:
*******************************************************************************
13:35:32.115 ["http-bio-8080"-exec-9] DEBUG o.a.j.core.session.SessionState
- Performed node.createQuery(SELECT * FROM [mmns:Asset] As asset WHERE
(Continue reading)

Permalink | Reply | 0 comments |

Gmane