Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Sender: Ildar Absalyamov <ty13r.derden@gmail.com>
From: Ildar Absalyamov <ildar.absalyamov@gmail.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_F07B9D24-2D4C-41AD-8998-C6BF3B2C6074"
Message-Id: <12157248-5D28-4A03-9958-435855FF7BBF@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Deadlock issue
Date: Thu, 18 Feb 2016 23:55:10 -0800
References: 
 <CAOQkTyPJV8=TLGBozJ=ibqNgY0byX54j62DfVdA+hEuQxhZimg@mail.gmail.com>
 <CAEEsEsQ3NaNu+Vr-UcMSz7wnCCFSXn2knEQ8MChtAHsQenczJg@mail.gmail.com>
 <CAOQkTyM3s6PFbQgG+cYQf0xgO=L6aftMSKHKswj=UXe2ntfszQ@mail.gmail.com>
 <CAOQkTyO9ibM8K4ey23FMXDTXYbnd5B61qSxXZENdpkJt0bKN_Q@mail.gmail.com>
To: dev@asterixdb.incubator.apache.org
In-Reply-To: 
 <CAOQkTyO9ibM8K4ey23FMXDTXYbnd5B61qSxXZENdpkJt0bKN_Q@mail.gmail.com>

--Apple-Mail=_F07B9D24-2D4C-41AD-8998-C6BF3B2C6074
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Abdullah,

Do you think that issue is somehow related to the patch that you =
proposed? https://issues.apache.org/jira/browse/ASTERIXDB-1302 =
<https://issues.apache.org/jira/browse/ASTERIXDB-1302>
It does not involve duplicates per se, but has the same issue with feed =
lock management.

> On Jan 7, 2016, at 09:12, abdullah alamoudi <bamousaa@gmail.com> =
wrote:
>=20
> So I have pushed the new change (Still under review).
>=20
> @Vignesh,
> This change has the fix for the twitter adapter.
>=20
> @Jianfeng,
> This change has the fix for the duplicate key issue.
>=20
> It can be checked out using
> git fetch https://asterix-gerrit.ics.uci.edu/asterixdb
> refs/changes/74/574/2 && git checkout FETCH_HEAD
>=20
> Amoudi, Abdullah.
>=20
> On Thu, Jan 7, 2016 at 7:42 PM, abdullah alamoudi <bamousaa@gmail.com>
> wrote:
>=20
>> Found the issue. It had nothing to do with any of the three =
components.
>>=20
>> The problem was that:
>>> 1. we remove the tuple causing the exception.
>> didn't work as I expected and instead it removed all the tuples upto =
the
>> offending record.
>> I have fixed it and now it works like a charm.
>>=20
>> Pushing the fix in a few minutes.
>> Abdullah.
>>=20
>> Amoudi, Abdullah.
>>=20
>> On Thu, Jan 7, 2016 at 6:16 PM, Mike Carey <dtabass@gmail.com> wrote:
>>=20
>>> The general transaction handling for such an exception wrt locking =
and
>>> aborts probably assumes that total bailouts are the answer.  Thus, =
it may
>>> leave messes that rollbacks are otherwise the answer to.  Feeds and
>>> transactions don't mix super well, it seems....  Watching how =
duplicate
>>> keys work for insert from query statements may help you debug. If we
>>> change
>>> things to allow those to succeed for all non duplicate keys - which =
might
>>> make more sense for that anyway.
>>> On Jan 7, 2016 5:48 AM, "abdullah alamoudi" <bamousaa@gmail.com> =
wrote:
>>>=20
>>>> Today, as I was working on fixing handling of duplicate keys with =
feeds,
>>>> everything seemed to work fine. here is what we do when we =
encounter a
>>>> duplicate key exception.
>>>>=20
>>>> 1. we remove the tuple causing the exception.
>>>> 2. we continue from where we stopped.
>>>>=20
>>>> The problem is that when I try to query the dataset after that to =
check
>>>> and see which records made it into the dataset, I get a deadlock.
>>>>=20
>>>> I have looked at the stack trace (attached) and I think the threads =
in
>>> the
>>>> file are the relevant ones. Please, have a look and let me know if =
you
>>> have
>>>> a possible cause in mind.
>>>>=20
>>>> The threads are related to:
>>>> 1. BufferCache.
>>>> 2. Logging.
>>>> 3. Locking.
>>>>=20
>>>> Let me know what you think. I can reproduce this bug. it happened =
on
>>> 100%
>>>> of my test runs.
>>>>=20
>>>> I will let you know when I solve it but it is taking longer than I
>>> thought.
>>>>=20
>>>> Amoudi, Abdullah.
>>>>=20
>>>=20
>>=20
>>=20

Best regards,
Ildar


--Apple-Mail=_F07B9D24-2D4C-41AD-8998-C6BF3B2C6074--