Hi,stefan: I got a jackrabbit clustering issue: Content created by one tomcat is not visible for another tomcat. Would you like to give me your configuration as a sample? Thanks in advance!
Stefan Guggisberg wrote: > > On Jan 16, 2008 7:33 PM, Connor Brett <[EMAIL PROTECTED]> wrote: >> I'm embarrassed to say my search problem is solved - I forgot to edit >> the node name in the cluster config! > > no problem, thanks for reporting back! :) > > cheers > stefan > >> >> >> -----Original Message----- >> From: Connor Brett [mailto:[EMAIL PROTECTED] >> Sent: 16 January 2008 17:01 >> To: [email protected] >> >> Subject: RE: Clusters >> >> Thanks, that's good news. What Jackrabbit version you are using? I don't >> see anything that stands out in our logs, no errors or warnings anyway. >> I haven't examined the entire log to look for the presense of >> re-indexing on other nodes. Is there anything I should be looking for, >> or any extra configuration I need to do for this to work? >> >> There's no evidence of index corruption - each cluster node can >> successfully find document nodes that _it_ added. We have in the past >> had the need to drop and re-create the indexes. In my test environment I >> started with a brand new repository so all cluster nodes have created >> their own local file system indexes. >> >> Thanks for your help. >> Brett >> >> >> -----Original Message----- >> From: Alessandro Bologna [mailto:[EMAIL PROTECTED] >> Sent: 16 January 2008 16:49 >> To: [email protected] >> Subject: Re: Clusters >> >> Regarding point 2, I can tell you that searching *does* work across >> clusters. When a clustered server adds, deletes or updates a JCR node, >> it writes a record in the journal table and the other servers are >> notified and they update their local lucene indexes. Those indexes need >> not to be on a shared filesystem. >> >> Sometimes we experimented a situation where the local indexes (stored on >> the filesystem, under repository/workspaces/<name>/index) on a server >> may have become corrupted, and that leads to queries returning no nodes. >> In those cases, it was enough to stop the server that fails, delete the >> contents of the index directory, and restart it. Indexes are >> regenerated, and it picks up any new change that has happened while it >> was down. >> Do you see anything weird in your logs? >> >> Alessandro >> >> >> >> >> On Jan 16, 2008 10:17 AM, Connor Brett <[EMAIL PROTECTED]> wrote: >> > We trying clusters with Jackrabbit 1.3.3, and I have a couple of >> > questions / issues: >> > >> > 1) journal database connection recovery - if / when the database is >> > offline the journal connection is never recovered, and errors are >> > repeatedly logged. Document operations seem to continue - errors are >> > logged but no exceptions are thrown. Nodes in the cluster are >> > presumably out of sync now. Does anyone know if this is recovered >> > cleanly next time the nodes restart or whether this is permanently >> > bad? I don't like even asking the question, but I'm being pressured to >> >> > hold off upgrading to >> > 1.4 at present. >> > >> > 2) searching doesn't seem to work over clusters, eg. add a document in >> >> > NODE-1, search for the document in NODE-1 works, search with the same >> > query in NODE-2 and the document is not found. The lucene indexes seem >> >> > to be in the local file system always, I can't find any other >> > configuration. Is there a way for the clusters to either share the >> > indexes or for JR to update the indexes from the journalled changes? >> > Does 1.4 change this (I didn't see anything in the release notes about >> >> > it)? >> > >> > Thanks >> > Brett >> >> E-MAIL DISCLAIMER >> The information in this e-mail and any attachment is confidential. It is >> intended only for the named recipient(s). If you are not a named >> recipient please notify the sender immediately and do not disclose the >> contents to another person or take copies. Although Axxia Systems has >> taken every reasonable precaution to ensure that any attachment to this >> e-mail has been checked for viruses,it is strongly recommended that you >> carry out your own virus check before opening any attachment, as we >> cannot accept liability for any damage sustained as a result of software >> virus infection. Axxia Systems reserves the right to monitor and record >> e-mails sent to axxia.com, and senders of such messages shall be taken to >> consent to this. >> Registered Office: Axxia House, Unit 4, The Pavilions, Ruscombe Business >> Park, Twyford, Berkshire, RG10 9NN. Registration Number: 3019229 >> >> > > -- View this message in context: http://www.nabble.com/Clusters-tp14884942p17269979.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
