Loading...

XML

Word

Printable

Details

Type: Bug
Resolution: Fixed
Priority: Blocker
Fix Version/s: 4.0.0
Affects Version/s: 4.0.0
Component/s: XDCR
Security Level: Public
Labels:
- ga
- system-test

Triage:
Untriaged
Operating System:
Centos 64-bit
Link to Log File, atop/blg, CBCollectInfo, Core dump:

Hide
Collecting logs from .51, will attach shortly.

https://s3.amazonaws.com/cb-customers/Aruna/collectinfo-2015-07-23T000700-ns_1%40172.23.105.61.zip

Show
Collecting logs from .51, will attach shortly. https://s3.amazonaws.com/cb-customers/Aruna/collectinfo-2015-07-23T000700-ns_1%40172.23.105.61.zip
Is this a Regression?:
Unknown

Description

Build

4.0.0-3490

Found in KV + XDCR + 2i + n1ql test

From a data + query node, the following replication error was encountered.

2015-07-22 16:46:54 172.23.105.51:xmem_424a76c2626a41770face72073ec50eb/ORDER_LINE/ORDER_LINE_172.23.105.61:11210_0:Empty docKey, req={MCRequest opcode=GET, bodylen=0, key=''}

Does this error mean that we are issuing a GET on an empty key at .61?

Attachments

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

Screen Shot 2015-07-23 at 9.44.51 AM.png
241 kB
23/Jul/15 11:14 AM

Gerrit Reviews

- Issue Only
- Show All Reviews
- Show Open Reviews
- Show All Issues
- Show Open Issues

No reviews matched the request. Check your Options in the drop-down menu of this sections header.

Activity

People

Assignee:: Aruna Piravi (Inactive)

Reporter:: Aruna Piravi (Inactive)

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 22/Jul/15 5:31 PM

Updated:: 30/Jul/15 9:12 AM

Resolved:: 24/Jul/15 11:18 PM

Gerrit Reviews

There are no open Gerrit changes

Show There is 1 closed Gerrit change

Hide There is 1 closed Gerrit change

MB-15805 GoXDCR: Replication error "Empty docKey, req={MCRequest opcode=GET, bodylen=0, key=''}" It is a racing condition when more than one DcpNozzles pass data to one XmemNozzle. XmemNozzle does two things when get the data - 1. put it in data channel; 2. accumuBatch where it put the big doc in bigDoc_map. The current implementation doesn't make 1 and 2 a unit of work. When more than one DcpNozzle try to pass data around the same time, the order of data1 and data 2 in data channel could be data1, data2, but it could be data2 enters accumuBatch first. If it happens the batch would be ready to move to ready queue after data 2 enters accumuBatch, it could be data 2 in big doc map of the batch, but when the batch is sent, data1 is the one that actually is being sent; and data1 would be in the bigDoc_map of the next batch. When the first batch is sent, data1 is recycled, so when doing getmeta on second batch, we see "Empty docKey" error: Gerrit Review:

PagerDuty