[GitHub] drill pull request: DRILL-4275: Refactor e/pstore interfaces and t...

[hnfgns]

Github user hnfgns commented on the pull request:

https://github.com/apache/drill/pull/325#issuecomment-173003718
  
How about anytime tomorrow from 10am till noon?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: query hanging in CANCELLATION_REQUEST

[Jacques Nadeau]

It sounds like the connection break is not correctly marking an ack fail.

--
Jacques Nadeau
CTO and Co-Founder, Dremio

On Tue, Jan 19, 2016 at 11:47 AM, Abdel Hakim Deneche  wrote:

> Ok, I will create a JIRA
>
> On Tue, Jan 19, 2016 at 11:45 AM, Hanifi Gunes 
> wrote:
>
> > I had reported this problem sometime last year verbally. I don't remember
> > creating a JIRA though. In general, I dislike this sort of blocking calls
> > anywhere in the execution even though one could argue it simplifies the
> > code flow.
> >
> > A JIRA would be appreciated.
> >
> > On Tue, Jan 19, 2016 at 11:10 AM, Abdel Hakim Deneche <
> > adene...@maprtech.com
> > > wrote:
> >
> > > I was running a query with a hash join that was generating lot's of
> > > results. I cancelled the query from sqlline then closed it. Now the
> query
> > > is stuck in CANCELLATION_REQUEST state.
> > >
> > > Looking at jstack it looks like screenRoot is blocked waiting for data
> > sent
> > > to the client to be acknowledged.
> > >
> > > Do we have a JIRA similar to this ?
> > >
> > > --
> > >
> > > Abdelhakim Deneche
> > >
> > > Software Engineer
> > >
> > >   
> > >
> > >
> > > Now Available - Free Hadoop On-Demand Training
> > > <
> > >
> >
> http://www.mapr.com/training?utm_source=Email_medium=Signature_campaign=Free%20available
> > > >
> > >
> >
>
>
>
> --
>
> Abdelhakim Deneche
>
> Software Engineer
>
>   
>
>
> Now Available - Free Hadoop On-Demand Training
> <
> http://www.mapr.com/training?utm_source=Email_medium=Signature_campaign=Free%20available
> >
>

Re: [DISCUSS] DRILL-4132

[Hanifi Gunes]

Do you want to create a doodle for this? [1]

-Hanifi

1: http://doodle.com/create

On Mon, Jan 18, 2016 at 11:02 PM, yuliya Feldman <
yufeld...@yahoo.com.invalid> wrote:

>
> Hello here,
> I wanted to start discussion on [1]
> Would be nice to have a hangout session with @jacques-n,
> @hnfgns, @StevenMPhillips
> Let me know suitable time
> Thanks,Yuliya
> [1] https://issues.apache.org/jira/browse/DRILL-4132

Drill Hangout Starting

[Jacques Nadeau]

https://plus.google.com/hangouts/_/dremio.com/drillhangout?authuser=0


--
Jacques Nadeau
CTO and Co-Founder, Dremio

[jira] [Created] (DRILL-4286) Have an ability to put server in quiescent mode of operation

[Victoria Markman (JIRA)]

Victoria Markman created DRILL-4286:
---

 Summary: Have an ability to put server in quiescent mode of 
operation
 Key: DRILL-4286
 URL: https://issues.apache.org/jira/browse/DRILL-4286
 Project: Apache Drill
  Issue Type: New Feature
  Components: Execution - Flow
Reporter: Victoria Markman


I think drill will benefit from mode of operation that is called "quiescent" in 
some databases. 

>From IBM Informix server documentation:
{code}
Change gracefully from online to quiescent mode
Take the database server gracefully from online mode to quiescent mode to 
restrict access to the database server without interrupting current processing. 
After you perform this task, the database server sets a flag that prevents new 
sessions from gaining access to the database server. The current sessions are 
allowed to finish processing. After you initiate the mode change, it cannot be 
canceled. During the mode change from online to quiescent, the database server 
is considered to be in Shutdown mode.
{code}

This is different from shutdown, when processes are terminated. 



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

Re: query hanging in CANCELLATION_REQUEST

[Hanifi Gunes]

I had reported this problem sometime last year verbally. I don't remember
creating a JIRA though. In general, I dislike this sort of blocking calls
anywhere in the execution even though one could argue it simplifies the
code flow.

A JIRA would be appreciated.

On Tue, Jan 19, 2016 at 11:10 AM, Abdel Hakim Deneche  wrote:

> I was running a query with a hash join that was generating lot's of
> results. I cancelled the query from sqlline then closed it. Now the query
> is stuck in CANCELLATION_REQUEST state.
>
> Looking at jstack it looks like screenRoot is blocked waiting for data sent
> to the client to be acknowledged.
>
> Do we have a JIRA similar to this ?
>
> --
>
> Abdelhakim Deneche
>
> Software Engineer
>
>   
>
>
> Now Available - Free Hadoop On-Demand Training
> <
> http://www.mapr.com/training?utm_source=Email_medium=Signature_campaign=Free%20available
> >
>

Re: [DISCUSS] DRILL-4132

[yuliya Feldman]

Great idea.
Created a poll [1]. Anybody interested can vote on time.
Thanks,Yuliya
[1] http://doodle.com/poll/c7w37sbvxh36k576


 

  From: Hanifi Gunes 
 To: dev@drill.apache.org; yuliya Feldman  
 Sent: Tuesday, January 19, 2016 11:44 AM
 Subject: Re: [DISCUSS] DRILL-4132
   
Do you want to create a doodle for this? [1]

-Hanifi

1: http://doodle.com/create

On Mon, Jan 18, 2016 at 11:02 PM, yuliya Feldman <
yufeld...@yahoo.com.invalid> wrote:

>
> Hello here,
> I wanted to start discussion on [1]
> Would be nice to have a hangout session with @jacques-n,
> @hnfgns, @StevenMPhillips
> Let me know suitable time
> Thanks,Yuliya
> [1] https://issues.apache.org/jira/browse/DRILL-4132


  

Re: query hanging in CANCELLATION_REQUEST

[Abdel Hakim Deneche]

Ok, I will create a JIRA

On Tue, Jan 19, 2016 at 11:45 AM, Hanifi Gunes  wrote:

> I had reported this problem sometime last year verbally. I don't remember
> creating a JIRA though. In general, I dislike this sort of blocking calls
> anywhere in the execution even though one could argue it simplifies the
> code flow.
>
> A JIRA would be appreciated.
>
> On Tue, Jan 19, 2016 at 11:10 AM, Abdel Hakim Deneche <
> adene...@maprtech.com
> > wrote:
>
> > I was running a query with a hash join that was generating lot's of
> > results. I cancelled the query from sqlline then closed it. Now the query
> > is stuck in CANCELLATION_REQUEST state.
> >
> > Looking at jstack it looks like screenRoot is blocked waiting for data
> sent
> > to the client to be acknowledged.
> >
> > Do we have a JIRA similar to this ?
> >
> > --
> >
> > Abdelhakim Deneche
> >
> > Software Engineer
> >
> >   
> >
> >
> > Now Available - Free Hadoop On-Demand Training
> > <
> >
> http://www.mapr.com/training?utm_source=Email_medium=Signature_campaign=Free%20available
> > >
> >
>



-- 

Abdelhakim Deneche

Software Engineer

  


Now Available - Free Hadoop On-Demand Training

[GitHub] drill pull request: DRILL-4131: Move RPC allocators under Drill's ...

[sudheeshkatkam]

Github user sudheeshkatkam commented on a diff in the pull request:

https://github.com/apache/drill/pull/327#discussion_r50167961
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/service/ServiceEngine.java 
---
@@ -56,22 +60,83 @@
   private final DrillConfig config;
   boolean useIP = false;
   private final boolean allowPortHunting;
+  private final BufferAllocator userAllocator;
+  private final BufferAllocator controlAllocator;
+  private final BufferAllocator dataAllocator;
+
 
   public ServiceEngine(ControlMessageHandler controlMessageHandler, 
UserWorker userWorker, BootStrapContext context,
   WorkEventBus workBus, WorkerBee bee, boolean allowPortHunting) 
throws DrillbitStartupException {
+userAllocator = newAllocator(context, "rpc:user", 
"drill.exec.rpc.user.server.memory.reservation",
+"drill.exec.rpc.user.server.memory.maximum");
+controlAllocator = newAllocator(context, "rpc:bit-control",
+"drill.exec.rpc.bit.server.memory.control.reservation", 
"drill.exec.rpc.bit.server.memory.control.maximum");
+dataAllocator = newAllocator(context, "rpc:bit-control",
--- End diff --

Can you please move the reservation and maximum string constants to 
ExecConstants?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (DRILL-4289) window functions give different results if star is used in inner query

[Deneche A. Hakim (JIRA)]

Deneche A. Hakim created DRILL-4289:
---

 Summary: window functions give different results if star is used 
in inner query
 Key: DRILL-4289
 URL: https://issues.apache.org/jira/browse/DRILL-4289
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning & Optimization
Affects Versions: 1.5.0
Reporter: Deneche A. Hakim


The following queries give different results, although they are similar:
{noformat}
SELECT position_id, COUNT(*) OVER w AS `count` FROM (SELECT position_id FROM 
`/b1p2tbl` ORDER BY employee_id, sub) WINDOW w AS (PARTITION BY position_id);
+--++
| position_id  | count  |
+--++
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 1| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
| 2| 10 |
+--++
{noformat}

{noformat}
SELECT position_id, COUNT(*) OVER w AS `count` FROM (SELECT * FROM 
dfs.data.`b1p2tbl` ORDER BY employee_id, sub) WINDOW w AS (PARTITION BY 
position_id);
+--++
| position_id  | count  |
+--++
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 1| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
| 2| 20 |
+--++
{noformat}

the results of the second query are incorrect.



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

[jira] [Created] (DRILL-4287) Do lazy reading of parquet metadata cache file

[Aman Sinha (JIRA)]

Aman Sinha created DRILL-4287:
-

 Summary: Do lazy reading of parquet metadata cache file
 Key: DRILL-4287
 URL: https://issues.apache.org/jira/browse/DRILL-4287
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning & Optimization
Affects Versions: 1.4.0
Reporter: Aman Sinha
Assignee: Aman Sinha


Currently, the parquet metadata cache file is read eagerly during creation of 
the DrillTable (as part of ParquetFormatMatcher.isReadable()).  This is not 
desirable from performance standpoint since there are scenarios where we want 
to do some up-front optimizations - e.g. directory-based partition pruning (see 
DRILL-2517) or potential limit 0 optimization etc. - and in such situations it 
is better to do lazy reading of the metadata cache file.   

This is a placeholder to perform such delayed reading since it is needed for 
the aforementioned optimizations.  



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

[jira] [Created] (DRILL-4288) Obsolete generated files under protocol/

[Laurent Goujon (JIRA)]

Laurent Goujon created DRILL-4288:
-

 Summary: Obsolete generated files under protocol/
 Key: DRILL-4288
 URL: https://issues.apache.org/jira/browse/DRILL-4288
 Project: Apache Drill
  Issue Type: Task
  Components: Tools, Build & Test
Reporter: Laurent Goujon
Priority: Trivial


The protocol module contains the following files directly at the root of the 
module:
{noformat}
protocol/org/apache/drill/exec/proto/BitControlHandshake.java
protocol/org/apache/drill/exec/proto/BitStatus.java
protocol/org/apache/drill/exec/proto/FragmentStatus.java
protocol/org/apache/drill/exec/proto/PlanFragment.java
protocol/org/apache/drill/exec/proto/RpcType.java
protocol/org/apache/drill/exec/proto/WorkQueueStatus.java
{noformat}

These files are not generated anymore when running {{mvn process-sources -P 
proto-compile}}



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

Re: Time for a 1.5 release?

[Jacques Nadeau]

Bumping this thread...

Here are the issues that were mentioned in this thread along with a
proposed categorization:

Release Blockers
In-progress Amit https://issues.apache.org/jira/browse/DRILL-4190
In-progress Amit https://issues.apache.org/jira/browse/DRILL-4196
Ready to merge Jacques https://issues.apache.org/jira/browse/DRILL-4246
In-review Jinfeng https://issues.apache.org/jira/browse/DRILL-4256
In-progress Jacques https://issues.apache.org/jira/browse/DRILL-4278
Ready to merge Laurent https://issues.apache.org/jira/browse/DRILL-4285
Nice to Have
Open Jason/Hakim https://issues.apache.org/jira/browse/DRILL-4247
In-progress Jason https://issues.apache.org/jira/browse/DRILL-4203
Open Jacques https://issues.apache.org/jira/browse/DRILL-4266
Ready to merge Jacques https://issues.apache.org/jira/browse/DRILL-4131

What do others think? Let's try to get the blockers wrapped up in the next
day or two and start a release vote...



--
Jacques Nadeau
CTO and Co-Founder, Dremio

On Mon, Jan 4, 2016 at 1:48 PM, Jason Altekruse 
wrote:

> Hello All,
>
> With the allocator changes merged and about a month since the last release
> I think it would be good to start a vote soon. I would like to volunteer to
> be release manager.
>
> I know that there were some issues that were identified after the transfer
> patch was merged. I think that these issues should be fixed before we cut a
> release candidate.
>
> From looking at the associated JIRAs it looked like there was a possible
> short term fix just adjusting the max_query_memory_per_node option, and
> some more involved work to change how we determine the correct time to
> spill during external sort. I believe it makes sense to make external sort
> work well with the newly improved memory accounting before cutting a
> release, but I'm not sure how much work is left to be done there. [1]
>
> Please respond with your thoughts on a release soon and any JIRAs you would
> like to include in the release.
>
> [1] - https://issues.apache.org/jira/browse/DRILL-4243
>
> Thanks,
> Jason
>

[GitHub] drill pull request: DRILL-4278: Fix issue where WorkspaceConfig wa...

[jaltekruse]

Github user jaltekruse commented on the pull request:

https://github.com/apache/drill/pull/331#issuecomment-173078753
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] drill pull request: DRILL-4091: Support for additional gis operati...

[k255]

Github user k255 commented on the pull request:

https://github.com/apache/drill/pull/258#issuecomment-172858385
  
Added new functionality to transform spatial reference of geometries (SRID) 
based on Proj4J.
Usage: ST_Transform(geom, srcSRID, tgtSRID)

This lets you transform SRID in drill without using external tools!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (DRILL-4282) Allow to customize address registered in zookeeper

[johnny (JIRA)]

johnny created DRILL-4282:
-

 Summary: Allow to customize address registered in zookeeper 
 Key: DRILL-4282
 URL: https://issues.apache.org/jira/browse/DRILL-4282
 Project: Apache Drill
  Issue Type: New Feature
  Components: Execution - RPC
Reporter: johnny


the useIP property in ServiceEngine is harecoded to false ,drill should allow 
to customize it.
User should be able to  specify the address  which register in the zookeeper  
to make drill cluster able to work with some cloud system like  kubernetes





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

[jira] [Created] (DRILL-4283) Experimental union type support is broken around ComplexWriterImpl

[Hanifi Gunes (JIRA)]

Hanifi Gunes created DRILL-4283:
---

 Summary: Experimental union type support is broken around 
ComplexWriterImpl
 Key: DRILL-4283
 URL: https://issues.apache.org/jira/browse/DRILL-4283
 Project: Apache Drill
  Issue Type: Bug
Reporter: Hanifi Gunes
Priority: Critical


VectorAccessibleComplexWriter#getWriter does not pass along the union flag 
while creating ComplexWriterImpl. This c'tor assumes union type is disabled.

To reproduce: i) enable union type ii) run a query over data with changing 
schema that uses ComplexWriterImpl like convert_from(..., 'JSON'). Query, then, 
should fail as though union type is not enabled.



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

[GitHub] drill pull request: Bumps FMPP version to 0.9.15

[jacques-n]

Github user jacques-n commented on the pull request:

https://github.com/apache/drill/pull/330#issuecomment-172900677
  
Can you update the PR commit message so that the naming pattern is 
consistent with Drill commits. The pattern is:

DRILL-: Short description

more description
more description
more description


Otherwise LGTM.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Please help clean up abandoned JIRAs marked REVIEWABLE

[Jason Altekruse]

I was able to close a few of the issues after finding that they had been
merged and just never had their status updated on JIRA. A few others have
been merged, but there are still a lot of these old patches outstanding. As
you have time please try to review anything you are currently assigned, if
there is work that is ready to merge, it would be good to keep the patches
from getting any more out of date.

Thanks,
Jason

On Tue, Jan 12, 2016 at 1:42 PM, Jason Altekruse 
wrote:

> Hello devs,
>
> I was trying to take a look at JIRA to make sure we weren't leaving out
> pending work that is ready to merge in the 1.5 release. It looks like we
> have a bunch of outstanding JIRAs (44) with a status of reviewable that
> haven't been merged.
>
> I will be taking a quick look through the list for anything that was
> changed more recently, but if you could please look at any issues currently
> assigned to you (because you were the contributor or reviewer) and please
> update to indicate that the patch should still be merged or has been
> abandoned. If it should still be merged, if you could please rebase the
> patches and update the reviews.
>
> Thanks for the help,
> Jason
>

[jira] [Created] (DRILL-4284) Complex Data Causing Index Out of Bounds with UNION Type

[John Omernik (JIRA)]

John Omernik created DRILL-4284:
---

 Summary: Complex Data Causing Index Out of Bounds with UNION Type 
 Key: DRILL-4284
 URL: https://issues.apache.org/jira/browse/DRILL-4284
 Project: Apache Drill
  Issue Type: Bug
  Components: Storage - JSON
Affects Versions: 1.4.0
Reporter: John Omernik


Working with complex json data and the UNION type, has shown a Index out of 
Bounds error when trying to read data.  Here are the posts from the Drill User 
Group:

After getting some pointers on the new experimental Union type with json, I 
started getting a different error related to index out of bounds, I thought I'd 
post here to determine what it could be, and if a bug, I can then open a JIRA. 

So first, I did:

ALTER SESSION SET `exec.errors.verbose` = true;  -- So I could get full errors 
ALTER SESSION SET `exec.enable_union_type` = true; -- So I could use the 
experimental UNION type 

Now, my first query, select * from `/data/prod/src/`  gave me the errors below. 
 The files change, and ironically, if I select directly from any specific file 
(even the ones in the error) often times the query works fine.  It's going 
through a directory of files that cause the error. Sometimes I Can do multiple 
files, but often times, but I come to one file, and it seems to break it.  The 
file that breaks things doesn't look different from others, but at the same 
time, I can select directly from the file, and it works... weird.  Let know if 
I can do anything to help troubleshoot more. 

Data Notes (see example below): 
- The ... represents LOTs of other fields, some simple, some complex/nested. 
This data is NOT Pretty. 
- The files are goofy in that each file has one top level field of "count" then 
a huge array of events
- The field that is ALWAYS (as far as I've seen) is the "features" field
- This field will sometimes be an array and sometimes be an empty object. {}.  
- The size of the array for the features field (when not an empty object) does 
change from event to event.  (My hunch is an issue there)
- This occurs even if I don't reference the features field, say I am trying to 
flatten a different field at the same level as features. 
Error:

Error: DATA_READ ERROR: index: 0, length: 4 (expected: range(0, 0))
 
File  /data/prod/src/file1.json
Record  1
Line  193
Column  34
Field  feature
Fragment 0:0
 
[Error Id: 25a2c963-86db-40e9-b5cc-2674887de2fe on node7:31010]
 
  (java.lang.IndexOutOfBoundsException) index: 0, length: 4 (expected: range(0, 
0))
io.netty.buffer.DrillBuf.checkIndexD():175
io.netty.buffer.DrillBuf.chk():197
io.netty.buffer.DrillBuf.getInt():477
org.apache.drill.exec.vector.UInt4Vector$Accessor.get():356
org.apache.drill.exec.vector.complex.ListVector$Mutator.startNewValue():305
org.apache.drill.exec.vector.complex.impl.UnionListWriter.startList():563

org.apache.drill.exec.vector.complex.impl.AbstractPromotableFieldWriter.startList():126
org.apache.drill.exec.vector.complex.impl.PromotableWriter.startList():42
org.apache.drill.exec.vector.complex.fn.JsonReader.writeData():461
org.apache.drill.exec.vector.complex.fn.JsonReader.writeData():305
org.apache.drill.exec.vector.complex.fn.JsonReader.writeData():470
org.apache.drill.exec.vector.complex.fn.JsonReader.writeData():305
org.apache.drill.exec.vector.complex.fn.JsonReader.writeDataSwitch():240
org.apache.drill.exec.vector.complex.fn.JsonReader.writeToVector():178
org.apache.drill.exec.vector.complex.fn.JsonReader.write():144
org.apache.drill.exec.store.easy.json.JSONRecordReader.next():191
org.apache.drill.exec.physical.impl.ScanBatch.next():191
org.apache.drill.exec.record.AbstractRecordBatch.next():119
org.apache.drill.exec.record.AbstractRecordBatch.next():109
org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():51

org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():132
org.apache.drill.exec.record.AbstractRecordBatch.next():162
org.apache.drill.exec.physical.impl.BaseRootExec.next():104
org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():81
org.apache.drill.exec.physical.impl.BaseRootExec.next():94
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():256
org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():250
java.security.AccessController.doPrivileged():-2
javax.security.auth.Subject.doAs():422
org.apache.hadoop.security.UserGroupInformation.doAs():1595
org.apache.drill.exec.work.fragment.FragmentExecutor.run():250
org.apache.drill.common.SelfCleaningRunnable.run():38
java.util.concurrent.ThreadPoolExecutor.runWorker():1142
java.util.concurrent.ThreadPoolExecutor$Worker.run():617
java.lang.Thread.run():745 (state=,code=0)



Example Data:

{
  "count": 241,
  "events": [
{
...
   

[jira] [Resolved] (DRILL-3042) where fails on fields converted to JSON

[Neeraja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neeraja resolved DRILL-3042.

Resolution: Fixed

Not reproducible in 1.4

> where fails on fields converted to JSON
> ---
>
> Key: DRILL-3042
> URL: https://issues.apache.org/jira/browse/DRILL-3042
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 0.9.0
>Reporter: Will Ochandarena
> Fix For: Future
>
> Attachments: WHEREfail.json
>
>
> See attached sample log from Google App Engine.  When I create a view of that 
> data that extracts an inner field and converts it to JSON -
> --
> create or replace view alltypes as select t3.line.status as status from 
> (select convert_from(line,'JSON') as line from (select t1.tp.logMessage as 
> line from(select flatten(t.protoPayload.line) as tp from 
> dfs.`/Users/wochandarena/Downloads/WHEREfail.json` t) as t1 where 
> t1.tp.logMessage LIKE '{%') as t2) as t3;
> --
> Then query the view with a where clause, the error below is seen.
> --
> 0: jdbc:drill:zk=local> select * from alltypes;
> ++
> |   status   |
> ++
> | Status |
> ++
> 1 row selected (0.345 seconds)
> 0: jdbc:drill:zk=local> select * from alltypes where status=Status;
> Query failed: SYSTEM ERROR: Unexpected exception during fragment 
> initialization: null
> [a1790b40-0055-4793-984f-b37ce72cb92f on 172.30.1.6:31010]
> Error: exception while executing query: Failure while executing query. 
> (state=,code=0)



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

[jira] [Created] (DRILL-4285) maven cannot find Could not find artifact org.freemarker:freemarker:jar:2.3.24-SNAPSHOT in apache.snapshots

[Laurent Goujon (JIRA)]

Laurent Goujon created DRILL-4285:
-

 Summary: maven cannot find Could not find artifact 
org.freemarker:freemarker:jar:2.3.24-SNAPSHOT in apache.snapshots
 Key: DRILL-4285
 URL: https://issues.apache.org/jira/browse/DRILL-4285
 Project: Apache Drill
  Issue Type: Bug
  Components: Tools, Build & Test
 Environment: MacOS 10.11, Java 7 (1.7.0_80), maven 3.2.x and 3.3.x
Reporter: Laurent Goujon
Priority: Minor


When building from master, build fails in component drill-fmpp-maven-plugin, 
with the following error message:
{noformat}
[ERROR] Failed to execute goal on project drill-fmpp-maven-plugin: Could not 
resolve dependencies for project 
org.apache.drill.tools:drill-fmpp-maven-plugin:maven-plugin:1.5.0-SNAPSHOT: 
Could not find artifact org.freemarker:freemarker:jar:2.3.24-SNAPSHOT in 
apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
{noformat} 

The project itself doesn't depend directly on the SNAPSHOT version, but FMPP 
dependency specifies a version range for FreeMarker.



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