Re: Errors with new cluster feature
Hi Miguel,
Yes, I'd be very interested in your PostgreSQL specific DDL to include
in the upcoming 1.3 release. Please note, that there has been a slight
schema change: I would appreciate if you could synchronize with
default.ddl in trunk.
Kind regards
Dominique
On 2/21/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote:
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 [EMAIL PROTECTED] wrote:
Hi Miguel
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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.
Re: Errors with new cluster feature
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 [EMAIL PROTECTED] wrote:
Hi Miguel
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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.
Re: Errors with new cluster feature
I'm working on some tests to reproduce this issue. However looking at the
code in 1.2.1, in method commit() of FileJournal.java, I can't find the lock
operation on the global revision file. Here is the code:
public void commit() throws JournalException {
try {
out.writeChar('\0');
out.close();
long nextRevision = record.getNextRevision();
FileRecordLog recordLog = new FileRecordLog(journal);
if (!recordLog.isNew()) {
if (nextRevision - recordLog.getFirstRevision()
maximumSize) {
switchLogs();
recordLog = new FileRecordLog(journal);
}
}
recordLog.append(record);
tempLog.delete();
globalRevision.set(nextRevision);
instanceRevision.set(nextRevision);
} catch (IOException e) {
String msg = Unable to close journal log + tempLog + : +
e.getMessage();
throw new JournalException(msg);
} finally {
out = null;
globalRevision.unlock();
writeMutex.release();
}
}
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.
Regards,
On 19/02/07, Dominique Pfister [EMAIL PROTECTED] wrote:
Hi Miguel,
writing to the journal log file should only be possible after having
obtained an exclusive lock on the global revision file (R), located in
the same directory as the journal log file (L). The exact sequence of
operations is as follows:
- exclusive lock is obtained on R
- journal entry appended to log file L
- revision counter is updated in R
- exclusive lock is released on R
This should rule out simultaneous writes to the log file L.
Are you easily able to reproduce this issue, starting with an empty
journal file? I could eliminate some small issues in the not yet
released 1.2.2 branch, but I still would be very glad to know more
about how and when this problem arises...
Kind regards
Dominique
On 2/14/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote:
Hi,
I'm trying the new cluster feature of Jackrabbit 1.2.1 and found some
issues. Using FileJournal to synchronize state between instances, we are
experiencing some errors that point to a possible corruption of the log
file:
2007-02-14 10:34:00,911 ERROR [org.apache.jackrabbit.core.RepositoryImpl
]
Unable to start clustered node, forcing shutdown...
org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate
over
modified records: malformed input around byte 178
at org.apache.jackrabbit.core.cluster.FileJournal.sync(
FileJournal.java
:313)
at org.apache.jackrabbit.core.cluster.ClusterNode.sync(
ClusterNode.java
:217)
at org.apache.jackrabbit.core.cluster.ClusterNode.start(
ClusterNode.java
:164)
at org.apache.jackrabbit.core.RepositoryImpl.init(
RepositoryImpl.java
:308)
at org.apache.jackrabbit.core.RepositoryImpl.create(
RepositoryImpl.java
:573)
at
org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(
BindableRepository.java:174)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(
BindableRepository.java:138)
at org.apache.jackrabbit.core.jndi.BindableRepository.create(
BindableRepository.java:125)
at
org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance
(
BindableRepositoryFactory.java:59)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository
(
RegistryHelper.java:60)
at
com.germinus.xpression.cms.jcr.EmbeddedRepositoryFactory.getRepository(
EmbeddedRepositoryFactory.java:50)
at com.germinus.xpression.cms.jcr.JCRUtil.initRepository(
JCRUtil.java
:243)
...
Caused by: java.io.UTFDataFormatException: malformed input around byte
178
at java.io.DataInputStream.readUTF(DataInputStream.java:639)
at org.apache.jackrabbit.core.cluster.FileRecord.readCreator(
FileRecord.java:242)
at org.apache.jackrabbit.core.cluster.FileRecord.init(
FileRecord.java
:106)
at org.apache.jackrabbit.core.cluster.FileRecordCursor.next(
FileRecordCursor.java:101)
at org.apache.jackrabbit.core.cluster.FileJournal.sync(
FileJournal.java
:303)
... 130 more
Perhaps I'm wrong but looks like two instances are writing the file
simultaneously. Is this behaviour known or misconfiguration? The journal
log
is placed in a shared folder on a Linux machine and exported by SAMBA to
the
instances. I have tested the lock file capabilities of the shared
filesystem
and they are ok.
--
Miguel.
--
Miguel.
Re: Errors with new cluster feature
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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
Re: Errors with new cluster feature
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?
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 [EMAIL PROTECTED] wrote:
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] 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.
Re: Errors with new cluster feature
Hi Miguel, writing to the journal log file should only be possible after having obtained an exclusive lock on the global revision file (R), located in the same directory as the journal log file (L). The exact sequence of operations is as follows: - exclusive lock is obtained on R - journal entry appended to log file L - revision counter is updated in R - exclusive lock is released on R This should rule out simultaneous writes to the log file L. Are you easily able to reproduce this issue, starting with an empty journal file? I could eliminate some small issues in the not yet released 1.2.2 branch, but I still would be very glad to know more about how and when this problem arises... Kind regards Dominique On 2/14/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote: Hi, I'm trying the new cluster feature of Jackrabbit 1.2.1 and found some issues. Using FileJournal to synchronize state between instances, we are experiencing some errors that point to a possible corruption of the log file: 2007-02-14 10:34:00,911 ERROR [org.apache.jackrabbit.core.RepositoryImpl] Unable to start clustered node, forcing shutdown... org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate over modified records: malformed input around byte 178 at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :313) at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java :217) at org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java :164) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java :308) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java :573) at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository( BindableRepository.java:174) at org.apache.jackrabbit.core.jndi.BindableRepository.init( BindableRepository.java:138) at org.apache.jackrabbit.core.jndi.BindableRepository.create( BindableRepository.java:125) at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance( BindableRepositoryFactory.java:59) at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository( RegistryHelper.java:60) at com.germinus.xpression.cms.jcr.EmbeddedRepositoryFactory.getRepository( EmbeddedRepositoryFactory.java:50) at com.germinus.xpression.cms.jcr.JCRUtil.initRepository(JCRUtil.java :243) ... Caused by: java.io.UTFDataFormatException: malformed input around byte 178 at java.io.DataInputStream.readUTF(DataInputStream.java:639) at org.apache.jackrabbit.core.cluster.FileRecord.readCreator( FileRecord.java:242) at org.apache.jackrabbit.core.cluster.FileRecord.init(FileRecord.java :106) at org.apache.jackrabbit.core.cluster.FileRecordCursor.next( FileRecordCursor.java:101) at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :303) ... 130 more Perhaps I'm wrong but looks like two instances are writing the file simultaneously. Is this behaviour known or misconfiguration? The journal log is placed in a shared folder on a Linux machine and exported by SAMBA to the instances. I have tested the lock file capabilities of the shared filesystem and they are ok. -- Miguel.
Errors with new cluster feature
Hi, I'm trying the new cluster feature of Jackrabbit 1.2.1 and found some issues. Using FileJournal to synchronize state between instances, we are experiencing some errors that point to a possible corruption of the log file: 2007-02-14 10:34:00,911 ERROR [org.apache.jackrabbit.core.RepositoryImpl] Unable to start clustered node, forcing shutdown... org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate over modified records: malformed input around byte 178 at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :313) at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java :217) at org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java :164) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java :308) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java :573) at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository( BindableRepository.java:174) at org.apache.jackrabbit.core.jndi.BindableRepository.init( BindableRepository.java:138) at org.apache.jackrabbit.core.jndi.BindableRepository.create( BindableRepository.java:125) at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance( BindableRepositoryFactory.java:59) at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository( RegistryHelper.java:60) at com.germinus.xpression.cms.jcr.EmbeddedRepositoryFactory.getRepository( EmbeddedRepositoryFactory.java:50) at com.germinus.xpression.cms.jcr.JCRUtil.initRepository(JCRUtil.java :243) ... Caused by: java.io.UTFDataFormatException: malformed input around byte 178 at java.io.DataInputStream.readUTF(DataInputStream.java:639) at org.apache.jackrabbit.core.cluster.FileRecord.readCreator( FileRecord.java:242) at org.apache.jackrabbit.core.cluster.FileRecord.init(FileRecord.java :106) at org.apache.jackrabbit.core.cluster.FileRecordCursor.next( FileRecordCursor.java:101) at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :303) ... 130 more Perhaps I'm wrong but looks like two instances are writing the file simultaneously. Is this behaviour known or misconfiguration? The journal log is placed in a shared folder on a Linux machine and exported by SAMBA to the instances. I have tested the lock file capabilities of the shared filesystem and they are ok. -- Miguel.
