Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <00030CE9-6A25-4450-9AFC-891632498280@gmail.com>
References: 
 <CAN_YF5xZ1nY9TMrN1cq4=b5HupF44NS50bKOHgQLhvfw7oN0GQ@mail.gmail.com>
 <31E8C4CE-CC21-43CF-9B1D-727BFA3EAAC6@gmail.com>
 <CAEEsEsSfZVOPPQA=TGfnmL-hK=ecgo3=-oGdLXkCG2GjdxquDQ@mail.gmail.com>
 <E376F4A4-A640-4392-8C80-0D8F4C266382@gmail.com>
 <CAN_YF5x64o_VUvu_OoH=RwQ6=JABPLG6L-V+vYmewhJKZKDxDg@mail.gmail.com>
 <CAN_YF5z2z7Zp4JkAG2gdssV9HUq5koabe+akorz7vC11TN_4KQ@mail.gmail.com>
 <5577DAAD.2030908@gmail.com>
 <CAN_YF5xim3ChLU+yJUKv_sbJRbR0q5Hfrdbr7h==D2gjhFxegQ@mail.gmail.com>
 <98BBEF2B-FB84-453E-A6A1-A0E43E0394C6@gmail.com>
 <CAN_YF5yjNtNJjPub7MJ2tzaho8L_QP5LsCpgDWT6wfeXeBcXYA@mail.gmail.com>
 <00030CE9-6A25-4450-9AFC-891632498280@gmail.com>
From: Ian Maxon <imaxon@uci.edu>
Date: Thu, 11 Jun 2015 17:28:19 -0700
Message-ID: 
 <CAN_YF5xopvJGQKrpLXQMVisbxNMVmBmBr2oTDgj3dnVpXDgoDQ@mail.gmail.com>
Subject: Re: Severe issue relating to indexing on nullable fields within a
 closed type?
To: dev@asterixdb.incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> > The locally produced Datatype object is actually never totally valid th=
ough
> > from the way I am seeing things. So there is no reason to cache it in t=
he
> > first place.
> >
>
> Indeed. But bypassing a cache is valid in this particular case only.
>

I think the crux of the problem though is that the MD node should
really be treating any object it receives to insert as final. Having
the client generate something to be inserted, then having the MD node
mutate that upon asking it to store the information, seems like it is
asking for trouble. It's certainly possible to do a delicate dance of
cache invalidation, but unless there's a good reason to do that- why
shouldn't we avoid it?

- Ian


On Thu, Jun 11, 2015 at 5:00 PM, Ildar Absalyamov
<ildar.absalyamov@gmail.com> wrote:
>
> Replies inline:
>
> > On Jun 11, 2015, at 16:28, Ian Maxon <imaxon@uci.edu> wrote:
> >
> > The locally produced Datatype object is actually never totally valid th=
ough
> > from the way I am seeing things. So there is no reason to cache it in t=
he
> > first place.
> >
>
> Indeed. But bypassing a cache is valid in this particular case only.
>
> >
> > I talked with Mike about this today. I think the main points were as
> > follows (correct me if I am wrong of course!):
> >
> > - Is it possible to move the name generation in DatatypeTupleTranslator
> > into TypeTranslator.computeTypes? This would let the client have the fu=
lly
> > updated object and avoid updating anything at the MD node side.
>
> I was thinking about this as well. Don=E2=80=99t quite see why that would=
 not be possible.
>
> >
> > - The entire type name generation seems weird. Why is it that we need t=
hose
> > names in the first place? For example take this type:
> >
> >
> > create type FacebookMessageType as closed {
> >        message-id: int32,
> >        author-id: int32,
> >        in-response-to: int32?,
> >        sender-location: point?,
> >        message: string
> >    }
> >
> > and the Metadata entry for that type:
> >
> > { "DataverseName": "TinySocial",
> >   "DatatypeName": "FacebookMessageType",
> >   "Derived": { "Tag": "RECORD",
> >                      "IsAnonymous": false,
> >                      "EnumValues": null,
> >                      "Record": { "IsOpen": false,
> >                                        "Fields": [ { "FieldName":
> > "message-id", "FieldType": "int32" },
> >                                                        { "FieldName":
> > "author-id", "FieldType": "int32" },
> >                                                        { "FieldName":
> > "in-response-to",
> >                                                          "FieldType":
> > "Field_in-response-to_in_FacebookMessageType"
> >                                                         },
> >                                                         { "FieldName":
> > "sender-location",
> >                                                        "FieldType":
> > "Field_sender-location_in_FacebookMessageType"
> >                                                         },
> >                                                         { "FieldName":
> > "message", "FieldType": "string" }
> >                                                       ]
> >                                       },
> >                      "Union": null,
> >                      "UnorderedList": null,
> >                      "OrderedList": null
> >    },
> >   "Timestamp": "Thu Jun 11 11:35:33 PDT 2015"
> > }
> >
> > Wouldn't it be better if we could make the Field entries for the nullab=
le
> > fields not dependent on this weird anonymous UNION(something,null) type=
?
> > Something more like
> >
> > { "FieldName": "in-response-to", "FieldType":"point", "Optional":true}
>
> Yeah, this whole naming thing might look weird, especially when it is app=
lied to nullable fields, which are in essence a primitive type.
> But for whatever reason we have chosen implementing a nullable fields as =
a a complex data type: union with null field. At the same time generating n=
ames for complex types is legitimate, and even required in case of anonymou=
s nested types, e.g:
>
> create type FacebookMessageType as closed {
>        message-id: int32,
>        author-id: int32,
>        in-response-to: int32?,
>        sender-location: {
>                 coordinate:point,
>                 POI: string
>         }?,
>        message: string
>    }
>
> >
> > We should definitely discuss this more on Friday
> >
> > - Ian
> >
> > On Wed, Jun 10, 2015 at 5:39 PM, Ildar Absalyamov <
> > ildar.absalyamov@gmail.com> wrote:
> >
> >> Just a bit of background, the bug is not specific to RTree, but will b=
e
> >> triggered on any index, created on a nullable field.
> >> In order to persist datatype with a nullable field a special internal =
type
> >> with name =E2=80=99Type_xxx_UnionType_yyy=E2=80=99 must be created on =
MD node side.
> >> However the stale version of datatype (where the name of the nullable
> >> field is not yet computed) is returned on the client, where it got cac=
hed.
> >>
> >> Clearly, relying on the fact that the argument supposedly passed by
> >> reference will get updated is wrong, when things are sent via RMI (and
> >> Ian=E2=80=99s patch resolves that).
> >> However I think a better way would be to invalidate locally cached sta=
le
> >> copy, so when the actual index is created it will query the MD and get=
 the
> >> right Datatype.
> >> That is in line with the question Niki (our visiting student from Germ=
any)
> >> asked me today, for which I did not had a clear answer: how do we mana=
ge
> >> the local MD cache and invalidate it?
> >>
> >>> On Jun 10, 2015, at 02:43, Ian Maxon <imaxon@uci.edu> wrote:
> >>>
> >>> Indeed, it is weird practice at best. The real index is an RTree inde=
x on
> >>> FacebookMessages.sender-location, which is nullable, and the code pat=
h to
> >>> create that index just happens to trigger this.
> >>>
> >>> On Tue, Jun 9, 2015 at 11:35 PM, Mike Carey <dtabass@gmail.com> wrote=
:
> >>>
> >>>> This sounds like a bad practice (doing any mods on the MD node - we
> >> should
> >>>> view the call as passing in immutable data).
> >>>> But I'm not sure which index is being referred to here - what index =
on
> >>>> what dataset is the "actual index" below?
> >>>>
> >>>>
> >>>>
> >>>> On 6/9/15 5:11 PM, Ian Maxon wrote:
> >>>>
> >>>>> So I think I might have a fix for this:
> >>>>> https://asterix-gerrit.ics.uci.edu/#/c/283/1
> >>>>>
> >>>>> This bug is really insidious. What I think is happening is that in
> >>>>> AqlTranslator, the types are computed and given to the MetadataMana=
ger
> >> as
> >>>>> a
> >>>>> new Datatype, to insert into the metadata node via RMI on MetadataN=
ode.
> >>>>> However MetadataNode modifies the object it is given before it inse=
rts
> >> it
> >>>>> into the actual index. That is where the names of the nullable type=
s
> >> get
> >>>>> generated, and so the MetadataManager doesn't get to see those chan=
ges
> >>>>> unless MetadataManager and MetadataNode are actually sharing the sa=
me
> >>>>> object. So if it is stale, that object gets inserted into the cache=
,
> >> and
> >>>>> when the index is created, it sees the stale type information rathe=
r
> >> than
> >>>>> the true value that's stored in the index.
> >>>>>
> >>>>> My fix is just to read it again before inserting into the cache. I'=
m
> >> not
> >>>>> really sure thats the right thing to do though. And if there are an=
y
> >> other
> >>>>> instances of this type (caller expecting changes on remote side to
> >>>>> reflect), the same sort of behavior can happen.
> >>>>>
> >>>>> - Ian
> >>>>>
> >>>>> On Tue, Jun 9, 2015 at 10:12 AM, Ian Maxon <imaxon@uci.edu> wrote:
> >>>>>
> >>>>> My quack theory is that it is due to the RMI somehow, or that the R=
MI
> >>>>>> reveals it. It isn't specific to managix. It happens as long as th=
e CC
> >>>>>> and
> >>>>>> NC reside in different JVMs.
> >>>>>>
> >>>>>> - Ian
> >>>>>>
> >>>>>> On Tue, Jun 9, 2015 at 10:03 AM, Ildar Absalyamov <
> >>>>>> ildar.absalyamov@gmail.com> wrote:
> >>>>>>
> >>>>>> As Ian mentioned test case already exists (which I thought was goo=
d
> >>>>>>> enough to prevent regressions like this one), but for some reason
> >> it=E2=80=99s
> >>>>>>> not
> >>>>>>> triggering the error, whereas if the same ddl\query is executed o=
n a
> >>>>>>> local
> >>>>>>> cluster, which was prepared by managix, the error will trigger.
> >>>>>>>
> >>>>>>> On Jun 9, 2015, at 08:07, Mike Carey <dtabass@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Ildar, can you try to nail this one down and also add a test cas=
e if
> >>>>>>>> you
> >>>>>>>> can create one once this is making more sense...?
> >>>>>>>> On Jun 8, 2015 11:58 PM, "Ildar Absalyamov" <
> >>>>>>>> ildar.absalyamov@gmail.com
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Interesting, I guess step 1 here would be to investigate what=E2=
=80=99s
> >>>>>>>>>
> >>>>>>>> different
> >>>>>>>
> >>>>>>>> in test framework\AsterixHyracksIntegrationUntil setup and regul=
ar
> >>>>>>>>>
> >>>>>>>> cluster
> >>>>>>>
> >>>>>>>> configuration, created by managix.
> >>>>>>>>>
> >>>>>>>>> On Jun 8, 2015, at 23:37, Ian Maxon <imaxon@uci.edu> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I was playing around with the latest snapshot version, trying =
to
> >>>>>>>>>>
> >>>>>>>>> create a
> >>>>>>>
> >>>>>>>> fresher version of my demo docker container, and so I ran throug=
h
> >> the
> >>>>>>>>>> ADM/AQL 101. However I couldn't get it to work, which was real=
ly
> >>>>>>>>>>
> >>>>>>>>> surprising
> >>>>>>>>>
> >>>>>>>>>> (and distressing). The error appears after trying to create an
> >> RTree
> >>>>>>>>>>
> >>>>>>>>> index
> >>>>>>>>>
> >>>>>>>>>> on
> >>>>>>>>>> sender-location:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> SEVERE: java.lang.NullPointerException
> >>>>>>>>>>
> >>>>>>>>>>> edu.uci.ics.asterix.metadata.MetadataException:
> >>>>>>>>>>> java.lang.NullPointerException
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.metadata.MetadataNode.addIndex(MetadataNode.java:2=
29)
> >>>>>>>
> >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j=
ava:62)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess=
orImpl.java:43)
> >>>>>>>
> >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> >>>>>>>
> >>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> >>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> >>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196=
)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:56=
8)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport=
.java:826)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$97(TCP=
Transport.java:683)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$2/1502895=
914.run(Unknown
> >>>>>>>
> >>>>>>>> Source)
> >>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.=
java:682)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j=
ava:1142)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.=
java:617)
> >>>>>>>
> >>>>>>>> at java.lang.Thread.run(Thread.java:745)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamR=
emoteCall.java:276)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:2=
53)
> >>>>>>>
> >>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Remot=
eObjectInvocationHandler.java:194)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvoc=
ationHandler.java:148)
> >>>>>>>
> >>>>>>>> at com.sun.proxy.$Proxy11.addIndex(Unknown Source)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.metadata.MetadataManager.addIndex(MetadataManager.=
java:417)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.aql.translator.AqlTranslator.handleCreateIndexStat=
ement(AqlTranslator.java:920)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.aql.translator.AqlTranslator.compileAndExecute(Aql=
Translator.java:261)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.api.http.servlet.APIServlet.doPost(APIServlet.java=
:97)
> >>>>>>>
> >>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> >>>>>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:84=
7)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:546)
> >>>>>>>>>
> >>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:=
483)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandle=
r.java:231)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandle=
r.java:970)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:4=
11)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler=
.java:192)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler=
.java:904)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.ja=
va:117)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.=
java:110)
> >>>>>>>
> >>>>>>>> at org.eclipse.jetty.server.Server.handle(Server.java:347)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.j=
ava:439)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpCon=
nection.java:924)
> >>>>>>>
> >>>>>>>> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:7=
81)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnectio=
n.java:43)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEnd=
Point.java:545)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndP=
oint.java:43)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.=
java:529)
> >>>>>>>
> >>>>>>>> at java.lang.Thread.run(Thread.java:745)
> >>>>>>>>>>> Caused by: java.lang.NullPointerException
> >>>>>>>>>>> at java.io.DataOutputStream.writeUTF(DataOutputStream.java:34=
7)
> >>>>>>>>>>> at java.io.DataOutputStream.writeUTF(DataOutputStream.java:32=
3)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.hyracks.dataflow.common.data.marshalling.UTF8StringSeriali=
zerDeserializer.serialize(UTF8StringSerializerDeserializer.java:44)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.dataflow.data.nontagged.serde.AStringSerializerDes=
erializer.serialize(AStringSerializerDeserializer.java:47)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.dataflow.data.nontagged.serde.AStringSerializerDes=
erializer.serialize(AStringSerializerDeserializer.java:26)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.formats.nontagged.AqlSerializerDeserializerProvide=
r$1.serialize(AqlSerializerDeserializerProvider.java:208)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.formats.nontagged.AqlSerializerDeserializerProvide=
r$1.serialize(AqlSerializerDeserializerProvider.java:189)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.metadata.entitytupletranslators.IndexTupleTranslat=
or.getTupleFromMetadataEntity(IndexTupleTranslator.java:260)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> edu.uci.ics.asterix.metadata.MetadataNode.addIndex(MetadataNode.java:2=
24)
> >>>>>>>
> >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j=
ava:62)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess=
orImpl.java:43)
> >>>>>>>
> >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> >>>>>>>
> >>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> >>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> >>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196=
)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:56=
8)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport=
.java:826)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$97(TCP=
Transport.java:683)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$2/1502895=
914.run(Unknown
> >>>>>>>
> >>>>>>>> Source)
> >>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>>>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.=
java:682)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j=
ava:1142)
> >>>>>>>
> >>>>>>>> at
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.=
java:617)
> >>>>>>>
> >>>>>>>> ... 1 more
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I started going back, trying this on older and older revisions
> >> until
> >>>>>>>>>>
> >>>>>>>>> it
> >>>>>>>
> >>>>>>>> stopped happening. It looks like this somehow has been lurking i=
n
> >> the
> >>>>>>>>>> Open/nested indexing code for a long time. The error does not
> >>>>>>>>>>
> >>>>>>>>> reproduce
> >>>>>>>
> >>>>>>>> in
> >>>>>>>>>
> >>>>>>>>>> the testing framework, for some reason I don't understand.
> >>>>>>>>>>
> >>>>>>>>>> The source of the bug seems to be that the RTree index is on a
> >> type
> >>>>>>>>>> of
> >>>>>>>>>> UNION(sender-location, null). The name of the type is not set
> >> like it
> >>>>>>>>>> should be, it is null. Then in IndexTupleTranslator, the 9th
> >> field of
> >>>>>>>>>>
> >>>>>>>>> the
> >>>>>>>
> >>>>>>>> new metadata record is written with the name of the type- which =
is
> >>>>>>>>>>
> >>>>>>>>> null,
> >>>>>>>
> >>>>>>>> so
> >>>>>>>>>
> >>>>>>>>>> everything explodes.
> >>>>>>>>>>
> >>>>>>>>>> What is especially puzzling- is that this doesn't reproduce in
> >>>>>>>>>> AsterixHyracksIntegrationUtil. There, the name of the type is
> >>>>>>>>>> "Field_sender-location_in_FacebookMessageType". This type is
> >> created
> >>>>>>>>>>
> >>>>>>>>> too
> >>>>>>>
> >>>>>>>> in
> >>>>>>>>>
> >>>>>>>>>> the deployed version, however it doesn't seem to be picked up.
> >>>>>>>>>>
> >>>>>>>>>> I will keep digging on this, but I imagine someone more famili=
ar
> >> with
> >>>>>>>>>>
> >>>>>>>>> the
> >>>>>>>
> >>>>>>>> Open/Nested indexing patch might have an idea about why this is
> >>>>>>>>>>
> >>>>>>>>> happening.
> >>>>>>>>>
> >>>>>>>>>> To reproduce just try deploying the snapshot version from the
> >> website
> >>>>>>>>>> normally on your machine, and run through ADM/AQL 101.
> >>>>>>>>>>
> >>>>>>>>>> - Ian
> >>>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Ildar
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>> Ildar
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>
> >> Best regards,
> >> Ildar
> >>
> >>
>
> Best regards,
> Ildar
>