Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
From: Jianfeng Jia <jianfeng.jia@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE258073-6EED-4F2F-B6B6-68A2FFB1BF5F"
Message-Id: <F4A150FF-30FF-47FC-9994-C93427CC136F@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Help! Any idea to stop AsterixDB from recovering?
Date: Mon, 16 May 2016 16:10:58 -0700
References: <4CB6C1F8-D0E8-4C4C-9B8B-42AE6B987AF5@gmail.com> <010902BB-7436-49BD-86D7-92C6384EF1B8@gmail.com> <9BE2BEEF-5FAD-4794-9B7A-2400213F855C@gmail.com> <CAEEsEsSonhod5SKg5BfYrDCdvZz_+qTWMJfs+v2J4XBvaJ6LbA@mail.gmail.com> <CAFUTFeaT0DxeuTiU0bZDEnMtpqVRGMaxkZF4osOWAwkEmqV9Lg@mail.gmail.com>
To: dev@asterixdb.incubator.apache.org
In-Reply-To: <CAFUTFeaT0DxeuTiU0bZDEnMtpqVRGMaxkZF4osOWAwkEmqV9Lg@mail.gmail.com>
archived-at: Mon, 16 May 2016 23:11:05 -0000

--Apple-Mail=_FE258073-6EED-4F2F-B6B6-68A2FFB1BF5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think the BuffeCache is the core issue, the recovery process may just =
run into the same spin trap where it was stopped.
And I create another issue that we should be able to Abort the task so =
that we don=E2=80=99t need to restart the server.

> On May 16, 2016, at 7:24 AM, Michael Blow <mblow.apache@gmail.com> =
wrote:
>=20
> This might be related: (ASTERIXDB-1438) BufferCache spins indefinitely =
when
> cache is exceeded.
>=20
> https://issues.apache.org/jira/browse/ASTERIXDB-1438
>=20
> Thanks,
>=20
> -MDB
>=20
> On Mon, May 16, 2016 at 1:52 AM Mike Carey <dtabass@gmail.com> wrote:
>=20
>> Glad it worked out - can someone also capture the core issue in JIRA? =
 Thx!
>> On May 15, 2016 11:40 PM, "Jianfeng Jia" <jianfeng.jia@gmail.com> =
wrote:
>>=20
>>> Great! The server is back now. Thanks a lot!
>>>> On May 15, 2016, at 2:26 PM, Murtadha Hubail <hubailmor@gmail.com>
>>> wrote:
>>>>=20
>>>> You can delete the existing log files and create new empty ones =
with
>>> incremented  log file number, but it is very important that you =
don't
>>> delete the checkpoint file.
>>>> Of course any data in the old log files will be lost, but the data
>>> already on disk will be available.
>>>>=20
>>>>> On May 15, 2016, at 1:23 PM, Jianfeng Jia <jianfeng.jia@gmail.com>
>>> wrote:
>>>>>=20
>>>>> Hi,
>>>>> We submitted a long running join+insert query and stop the cluster =
to
>>> stop running it. However, when it restarted it ran the recovery =
forever,
>>>>> the logs shows that it is creating a lot of buffer cache.
>>>>>=20
>>>>> In order to bring the cluster back to answer the query, is there =
any
>>> hacking solutions? such as remove the recovery txnlogs? I=E2=80=99m =
worried that
>> it
>>> will ruin the cluster somehow.
>>>>> We are in a contest so any early helps are really appreciated! =
Thanks!
>>>>>=20
>>>>>=20
>>>>> Best,
>>>>>=20
>>>>> Jianfeng Jia
>>>>> PhD Candidate of Computer Science
>>>>> University of California, Irvine
>>>>>=20
>>>=20
>>>=20
>>>=20
>>> Best,
>>>=20
>>> Jianfeng Jia
>>> PhD Candidate of Computer Science
>>> University of California, Irvine
>>>=20
>>>=20
>>=20


Best,

Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine


--Apple-Mail=_FE258073-6EED-4F2F-B6B6-68A2FFB1BF5F--