[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202362#comment-13202362
 ] 

Philipp Sushkin edited comment on BOOKKEEPER-162 at 2/7/12 1:37 PM:
--------------------------------------------------------------------

I started to debug and do have small question.

Same case 1 writer, 1 reader.
Reader tries to request lastAddConfirmed.

On server side I see there is header:
{panel}
[1, 2, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 2,
 -1, -1, -1, -1, -1, -1, -1, -1]
{panel}

built in BookieServer
{code}
    private ByteBuffer buildResponse(int errorCode, byte version, byte opCode, 
long ledgerId, long entryId) {
        ByteBuffer rsp = ByteBuffer.allocate(24);
        rsp.putInt(new PacketHeader(version, 
                                    opCode, (short)0).toInt());
        rsp.putInt(errorCode);
        rsp.putLong(ledgerId);
        rsp.putLong(entryId);

        rsp.flip();
        return rsp;
    }
{code}

EntryId here -1, because I was requesting last confirmed.
Request looked like
{panel}
[1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, -1, -1, -1, -1, -1, -1, -1, -1]
{panel}

Also data itself, in EntryLogger
{code}
byte[] readEntry(long ledgerId, long entryId, long location) throws IOException 
{
...
        byte data[] = new byte[entrySize];
        ByteBuffer buff = ByteBuffer.wrap(data);
        int rc = fc.read(buff, pos);
 ...

I see 
 [0, 0, 0, 0, 0, 0, 0, 2,
 0, 0, 0, 0, 0, 0, 0, 1,
 -1, -1, -1, -1, -1, -1, -1, -1,
 0, 0, 0, 0, 0, 0, 0, 2,
 -16, 41, -22, 25, 26, 93, -80, -40, -80, -15, 7, -36, 72, -52, 13, -54, 39, 
117, 12, -56, 2]
    }
{code}

On client in 

DigestManager
{code}
    RecoveryData verifyDigestAndReturnLastConfirmed(ChannelBuffer dataReceived) 
throws BKDigestMatchException {
        verifyDigest(dataReceived);
        dataReceived.readerIndex(8);

        long entryId = dataReceived.readLong();
        long lastAddConfirmed = dataReceived.readLong();
        long length = dataReceived.readLong();
        return new RecoveryData(lastAddConfirmed, entryId);

    }
{code}

I see (reader offset 24 after "dataReceived.readerIndex(8);")
{panel}
[1, 2, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 2,
 -1, -1, -1, -1, -1, -1, -1, -1, 
 0, 0, 0, 0, 0, 0, 0, 2,  < ledgerId
 0, 0, 0, 0, 0, 0, 0, 1,  < long entryId = dataReceived.readLong();
 -1, -1, -1, -1, -1, -1, -1, -1, < long lastAddConfirmed = 
dataReceived.readLong(); *PROBLEM HERE*
 0, 0, 0, 0, 0, 0, 0, 2,
 -16, 41, -22, 25, 26, 93, -80, -40, -80, -15, 7, -36, 72, -52, 13, -54, 39, 
117, 12, -56, 2]
{panel}


So, am I right: lastAddConfirmed is a part of record, not calculated on request?

                
      was (Author: philipp.sushkin):
    I started to debug and do have small question.


Same case 1 writer, 1 reader.
Reader tries to request lastAddConfirmed.

On server side I see there is header:
{panel}
[1, 2, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 2,
 -1, -1, -1, -1, -1, -1, -1, -1]
{panel}

built in BookieServer
{code}
    private ByteBuffer buildResponse(int errorCode, byte version, byte opCode, 
long ledgerId, long entryId) {
        ByteBuffer rsp = ByteBuffer.allocate(24);
        rsp.putInt(new PacketHeader(version, 
                                    opCode, (short)0).toInt());
        rsp.putInt(errorCode);
        rsp.putLong(ledgerId);
        rsp.putLong(entryId);

        rsp.flip();
        return rsp;
    }
{code}

EntryId here -1, because I was requesting last confirmed.
Request looked like
{panel}
[1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, -1, -1, -1, -1, -1, -1, -1, -1]
{panel}

Also data itself, in EntryLogger
{code}
byte[] readEntry(long ledgerId, long entryId, long location) throws IOException 
{
...
        byte data[] = new byte[entrySize];
        ByteBuffer buff = ByteBuffer.wrap(data);
        int rc = fc.read(buff, pos);
 ...

I see 
 [0, 0, 0, 0, 0, 0, 0, 2,
 0, 0, 0, 0, 0, 0, 0, 1,
 -1, -1, -1, -1, -1, -1, -1, -1,
 0, 0, 0, 0, 0, 0, 0, 2,
 -16, 41, -22, 25, 26, 93, -80, -40, -80, -15, 7, -36, 72, -52, 13, -54, 39, 
117, 12, -56, 2]
    }
{code}

On client in 

DigestManager
{code}
    RecoveryData verifyDigestAndReturnLastConfirmed(ChannelBuffer dataReceived) 
throws BKDigestMatchException {
        verifyDigest(dataReceived);
        dataReceived.readerIndex(8);

        long entryId = dataReceived.readLong();
        long lastAddConfirmed = dataReceived.readLong();
        long length = dataReceived.readLong();
        return new RecoveryData(lastAddConfirmed, entryId);

    }
{code}

I see (reader offset 24 after "dataReceived.readerIndex(8);")
{panel}
[1, 2, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 2,
 -1, -1, -1, -1, -1, -1, -1, -1, 
 0, 0, 0, 0, 0, 0, 0, 2,  <- ledgerId
 0, 0, 0, 0, 0, 0, 0, 1,  <- long entryId = dataReceived.readLong();
 -1, -1, -1, -1, -1, -1, -1, -1, <- long lastAddConfirmed = 
dataReceived.readLong(); *PROBLEM HERE*
 0, 0, 0, 0, 0, 0, 0, 2,
 -16, 41, -22, 25, 26, 93, -80, -40, -80, -15, 7, -36, 72, -52, 13, -54, 39, 
117, 12, -56, 2]
{panel}


So, am I right: lastAddConfirmed is a part of record, not calculated on request?

                  
> LedgerHandle.readLastConfirmed does not work
> --------------------------------------------
>
>                 Key: BOOKKEEPER-162
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-162
>             Project: Bookkeeper
>          Issue Type: Bug
>          Components: bookkeeper-client
>    Affects Versions: 4.0.0
>            Reporter: Philipp Sushkin
>            Assignee: Flavio Junqueira
>            Priority: Critical
>             Fix For: 4.0.0
>
>         Attachments: BOOKKEEPER-162.patch, BOOKKEEPER-162.patch, 
> BookieReadWriteTest.java.patch, BookieReadWriteTest.java.patch, 
> BookieReadWriteTest.java.patch, bookkeeper.log
>
>
> Two bookkeeper clients.
> 1st continuously writing to ledger X.
> 2nd (bk.openLedgerNoRecovery) polling ledger X for new entries and reading 
> them.
> In response we always reveiceing 0 as last confirmed entry id (in fact we are 
> receiving -1 from each bookie RecoveryData but then in ReadLastConfirmedOp, 
> but uninitialized "long maxAddConfirmed;" takes priority in Math.max(...).
> Main question - is given scenario is expected to work at all?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to