jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miguel Ángel Jiménez" <miguel...@gmail.com>
Subject Re: Errors with new cluster feature
Date Wed, 21 Feb 2007 10:56:27 GMT
Hi,

I'm testing the new DatabaseJournal with a PostgreSQL. Since there was no
ddl for this database I had to generate one and thought you could upload it
to subversion.

Regards,

On 21/02/07, Dominique Pfister <dominique.pfister@day.com> wrote:
>
> Hi Miguel
>
> On 2/20/07, Miguel Ángel Jiménez <miguel.js@gmail.com> wrote:
> > Thanks again for the response. I have another issue about FileJournal.
> In
> > our test environment, we have several instances doing concurrent
> > modifications to the repository and have been able to trace what I see
> as a
> > possible bug in log file rotation. It seems that the renaming of old
> files
> > is not working as expected. For example, journal.log.1 does not get
> renamed
> > to journal.log.2 when rotating the current log file. I think the problem
> is
> > class FileJournal method switchLogs:
> >
> > String newName = name.substring(0, sep + 1) + String.valueOf(version +
> 1);
> > file.renameTo(new File(newName));
> >
> > The new name does not preserve the original path of the renamed file.
> > Wouldn't be better to do...
> >
> > String newName = name.substring(0, sep + 1) + String.valueOf(version +
> 1);
> > file.renameTo(new File(root, newName));
> >
> > ... or something similar? Makes it sense to you?
>
> Absolutely! I fixed this only yesterday while fixing some other issues
> (JCR-749,JCR-756,JCR-757) as well. Great bug tracking work!
>
> Kind regards
> Dominique
>
> >
> > Thanks for the advance on the new DatabaseJournal. I'm looking forward
> to
> > this solution as it suits well with our current deployment model.
> >
> > Kind regards,
> >
> >
> >
> >
> >
> > On 20/02/07, Dominique Pfister <dominique.pfister@day.com> wrote:
> > >
> > > Hi Miguel,
> > >
> > > On 2/20/07, Miguel Ángel Jiménez <miguel.js@gmail.com> wrote:
> > > > The call to globalRevision.set (that implies a lock) is done after
> the
> > > call
> > > > to recordLog.append() so I think the write is not protected. I'm
> rather
> > > new
> > > > to JCR and jackrabbit so maybe I'm missing something but the cluster
> > > feature
> > > > is very important for our product. I'm going to develop some classes
> to
> > > test
> > > > basic cluster operation and hope it helps to further improve in this
> > > area.
> > >
> > > Well, the method FileJournal.prepare() exclusively locks the global
> > > revision:
> > >
> > >   public void prepare() throws JournalException {
> > >       globalRevision.lock(false);
> > >       ...
> > >   }
> > >
> > > and this method is called before the actual FileJournal.commit().
> > >
> > > In Jackrabbit 1.2.2, a DatabaseJournal has been added, that stores its
> > > record in a shared database. If the persistence managers you're using
> > > already share a standalone database, this might be an option.
> > >
> > > Kind regards
> > > Dominique
> > >
> >
> >
> >
> > --
> > Miguel.
> >
>



-- 
Miguel.

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message