You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Ian Boston (JIRA)" <ji...@apache.org> on 2007/05/13 21:21:15 UTC
[jira] Commented: (JCR-915) Invalid Journal Record appearing when
read during sync operation
[ https://issues.apache.org/jira/browse/JCR-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495403 ]
Ian Boston commented on JCR-915:
--------------------------------
Using the 1.3 tag source
I have put some debug statements in the AppendRecord class and the ReadRecord Class to record all the write and read operations respectively.
The Revision in question 3161 has some strange charateristics.
The Write trace is
Write String :0:sakai
Write Char :0:L:Ox4c
Write Byte :0:76:Ox4c
Write Fully :0: 0x47 0xffffff98 0xf 0x1e 0xffffffc6 0xffffffc0 0x43 0xffffffb4 0xffffff99 0xffffffe5 0xffffffdb 0x18 0xffffffe6 0x4e 0x2b 0x6f (END)
As String G???C?????N+o
Write Boolean :0:false
Writing Journal JR:localhost1:3161:28
Written :3161:28
Where the format is
Action:revision:more data
Writing Journal JR:localhost1:3161:28 meaning that localhost1 wrote revision 3161 length 28 bytes
The read for the same Journal Record on the second node is
Read record JR:localhost1:3161:28
Read String :3161:sakai
Read Char :3161:L:Ox4c
Read Byte :3161:Ox4c
Read Fully :3161: 0x47 0xffffff98 0xf 0x1e 0xffffffc6 0xffffffc0 0x43 0xffffffb4 0xffffff99 0xffffffe5 0xffffffdb 0x18 0xffffffe6 0x4e 0x2b 0x6f (END)
As String G???C?????N+o
Read Boolean :3161:false
Read Char :3161:
:Oxa
ERROR: Error while processing revision 3161: Unknown entry type:
(a) (2007-05-13 19:57:02,258 main_org.apache.jackrabbit.core.cluster.ClusterNode)
ERROR: Unable to start clustered node, forcing shutdown... (2007
Which all looks OK...... every other record is terminated with a 0x0 byte.
If I look at the next record that was written
Write String :0:sakai
Write Char :0:L:Ox4c
Write Byte :0:76:Ox4c
Write Fully :0: 0x47 0xffffff98 0xf 0x1e 0xffffffc6 0xffffffc0 0x43 0xffffffb4 0xffffff99 0xffffffe5 0xffffffdb 0x18 0xffffffe6 0x4e 0x2b 0x6f (END)
As String G???C?????N+o
Write Boolean :0:true
Write Boolean :0:false
Write String :0:admin
Write Char :0::Ox0
Writing Journal JR:localhost1:3220:39
Written :3220:39
It ended with 0x0, which would have terminated the entry
It looks like the boolean written at the end of the 3161 revision indicates something odd, and there is no 0x0 being output after that ?
I will have a further look as it appears to be a L record ?
> Invalid Journal Record appearing when read during sync operation
> ----------------------------------------------------------------
>
> Key: JCR-915
> URL: https://issues.apache.org/jira/browse/JCR-915
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.3
> Environment: OSX 10.4, JDK 1.5
> Reporter: Ian Boston
>
> ERROR: Error while processing revision 3161: Unknown entry type:
> (a) (2007-05-13 19:57:02,258 main_org.apache.jackrabbit.core.cluster.ClusterNode)
> ERROR: Unable to start clustered node, forcing shutdown... (2007-05-13 19:57:02,259 main_org.apache.jackrabbit.core.RepositoryImpl)
> org.apache.jackrabbit.core.cluster.ClusterException: Unable to read record with revision: 3161
> at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java:285)
> at org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java:229)
> at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:308)
> at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584)
> at org.sakaiproject.jcr.jackrabbit.RepositoryBuilder.init(RepositoryBuilder.java:213)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> This is a 2 node cluster, with persistance managers in the DB and journal on the shared filesystem.
> Start the first node in the cluster up from a completely clean and empty repo.
> Let it add some note types, and create a since workspace (called sakai) and then connect via webdav (using OSX Finder) which creates some Journal Records (due to the finder putting some .xxxx files in)
> Dont add any files.
> Then start the second node in the cluster up,
> It runs through the first 15 or so journal entries and then hits a one where the entry is unknown (stack trace above)
> Some analysis to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.