Mailing-List: contact notifications-help@asterixdb.incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Date: Sat, 16 Jan 2016 02:09:39 +0000 (UTC)
From: "Till Westmann (JIRA)" <jira@apache.org>
To: notifications@asterixdb.incubator.apache.org
Message-ID: <JIRA.12929637.1452645289000.128485.1452910179789@Atlassian.JIRA>
In-Reply-To: <JIRA.12929637.1452645289000@Atlassian.JIRA>
References: <JIRA.12929637.1452645289000@Atlassian.JIRA>
 <JIRA.12929637.1452645289165@arcas>
Subject: [jira] [Commented] (ASTERIXDB-1261) The UUID printer shares an
 object across partitions, leading to a concurrency problem
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Till Westmann commented on ASTERIXDB-1261:
------------------------------------------

I thought that we didn't have those anymore. But I hope that the answer is simple. Instead of returning the same printer instance every time, the factory needs to return a new instance every time. And those instances should then be reused by every NodePushable that works in a single thread.
Is that right?

> The UUID printer shares an object across partitions, leading to a concurrency problem
> -------------------------------------------------------------------------------------
>
>                 Key: ASTERIXDB-1261
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1261
>             Project: Apache AsterixDB
>          Issue Type: Bug
>            Reporter: Steven Jacobs
>         Attachments: Screen Shot 2016-01-12 at 4.28.42 PM.png
>
>
> The UUID printer currently shares a mutable uuid across all partitions, which cause a concurrency issue where the value is printer incorrectly. We need to add a function to print uuid values without creating objects, as other printers (e.g. circle) do. 
> You can see the problem in action using the following:
> drop dataverse channels if exists;
> create dataverse channels;
> use dataverse channels;
> create type TypeA as closed
> { "resultId":uuid, "subscriptionId":uuid, "deliveryTime":datetime }
> create dataset nearbyTweetChannelResults(TypeA) primary key resultId auto generated;
> insert into dataset nearbyTweetChannelResults(
> {"subscriptionId":uuid("d0b6fac0-3903-43dc-8ef6-7b0923ffc759"), "deliveryTime":datetime("2011-08-25T10:10:00.000Z")}
> );
> insert into dataset nearbyTweetChannelResults(
> {"subscriptionId":uuid("d0b6fac0-3903-43dc-8ef6-7b0923ffc759"), "deliveryTime":datetime("2011-08-25T10:10:00.000Z")}
> );
> Next, run the following AQL repeatedly. It should change within 20 or so times.
> use dataverse channels;
> for $result in dataset nearbyTweetChannelResults
> return $result.resultId;
> for $result in dataset nearbyTweetChannelResults
> return $result.resultId;
> for $result in dataset nearbyTweetChannelResults
> return $result.resultId;
> I have a screenshot of a failed instance that I will try to attach. The first result in the screenshot is clearly wrong


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)