jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Boston (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-915) Invalid Journal Record appearing when read during sync operation
Date Sun, 13 May 2007 19:21:15 GMT

    [ 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.


Mime
View raw message