[jira] [Created] (DRILL-6522) Admission control information in docs is out of date
Paul Rogers created DRILL-6522: -- Summary: Admission control information in docs is out of date Key: DRILL-6522 URL: https://issues.apache.org/jira/browse/DRILL-6522 Project: Apache Drill Issue Type: Bug Affects Versions: 1.13.0 Reporter: Paul Rogers Assignee: Bridget Bevens Drill supports admission control as describe [in the docs|http://example.com/]. However, this information is out of date. We extensively revised this feature at the end of 2017. I seem to recall providing a complete documentation of the feature, and even reviewing draft documentation. However, none of that material is currently in the documentation on the web site. The original material is likely in the internal MapR Google Docs directory in the "Resource Management" folder. It was, as I recall, named something like "Resource Management for Drill 1.xx" for some xx. Please locate the "missing" documentation and/or the source material sited above, and add the material to the Drill online documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-6521) When using Hadoop configs, allow dfs connection to be unset
Paul Rogers created DRILL-6521:
--
Summary: When using Hadoop configs, allow dfs connection to be
unset
Key: DRILL-6521
URL: https://issues.apache.org/jira/browse/DRILL-6521
Project: Apache Drill
Issue Type: Improvement
Affects Versions: 1.13.0
Reporter: Paul Rogers
Drill usually works stand-alone. In a Hadoop HDFS environment, the docs. say to
set the HDFS configuration in the storage plugin config.
In a MapR installation, MaprFS settings are applied automatically.
However, when Drill runs on an existing HDFS cluster, one must often provide
more than the simple HDFS URL. Particularly in a secure cluster, other
configuration settings are also needed. At present, these must be copied out of
the HDFS config files into the Drill storage plugin config, and the two must be
updated in tandem. Clearly less than ideal.
Drill does allow the user to add Hadoop configs to the class path. (Though, it
looks like in recent releases the previous {{HADOOP_CONF}} setting has been
removed.) The user can edit {{drill-env.sh}} to add the Hadoop class path to
{{EXTN_CLASSPATH}}. (But see DRILL-6520.)
This is all good, but Drill still requires that the "dfs" storage plugin config
contain a connection. Omit the connection and we get:
{noformat}
Please retry: Error while creating/ updating storage : The value of property
fs.defaultFS must not be null
{noformat}
Would expect to be able to omit this property if the value is provided by the
standard Hadoop {{core-site.xml}} file (and to do so without Drill crashing,
per DRILL-6520).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-6520) Setting fs.defaultFS in core-site.xml causes startup crash
Paul Rogers created DRILL-6520:
--
Summary: Setting fs.defaultFS in core-site.xml causes startup crash
Key: DRILL-6520
URL: https://issues.apache.org/jira/browse/DRILL-6520
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Paul Rogers
In a Hadoop HDFS environment, the docs. say to set the HDFS configuration in
the storage plugin config.
However, when Drill runs on an existing HDFS cluster, one must often provide
more than the simple HDFS URL. Particularly in a secure cluster, other
configuration settings are also needed. At present, these must be copied out of
the HDFS config files into the Drill storage plugin config, and the two must be
updated in tandem. Clearly less than ideal.
In experimenting with better integration, I added my HDFS {{core-site.xml}}
file to the class path, hoping Drill would pick up the settings from the Hadoop
config files that I had placed on the class path. Instead, Drill failed to
start.
{noformat}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.drill.exec.coord.zk.ZKClusterCoordinator.update(ZKClusterCoordinator.java:218)
at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:228)
at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:401)
at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:372)
at org.apache.drill.exec.server.Drillbit.main(Drillbit.java:368)
{noformat}
Modify the {{core-site.xml}} file to comment out the {{fs.defaultFS}} property.
{noformat}
{noformat}
Now Drill starts fine.
The "myNameNode" is not the real name. But, the actual value here is identical
to the value set in the dfs "connection" property, which works fine by itself
without {{core-site.xml}}.
Expected that Drill would allow the common Hadoop pattern of setting
{{fs.defaultFS}} in {{core-site.xml}}. At the very least, Drill should not
crash when this (or any other) property is set in {{core-site.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-6519) Add String Distance and Phonetic Functions
Charles Givre created DRILL-6519:
Summary: Add String Distance and Phonetic Functions
Key: DRILL-6519
URL: https://issues.apache.org/jira/browse/DRILL-6519
Project: Apache Drill
Issue Type: Improvement
Affects Versions: 1.14.0
Reporter: Charles Givre
Assignee: Charles Givre
>From a recent project, this collection of functions makes it possible to do
>fuzzy string matching as well as phonetic matching on strings.
The following functions are all phonetic functions and map text to a number or
string based on how the word sounds. For instance "Jayme" and "Jaime" have the
same soundex values and hence these functions can be used to match similar
sounding words.
* caverphone1( )
* caverphone2( )
* cologne_phonetic( )
* dm_soundex( )
* double_metaphone()
* match_rating_encoder( )
* metaphone()
* nysiis( )
* refined_soundex()
* soundex()
Additionally, there is the
{code:java}
sounds_like(,){code}
function which can be used to find strings that sound similar. For instance:
{code:java}
SELECT *
FROM
WHERE sounds_like( last_name, 'Gretsky' )
{code}
h2. String Distance Functions
In addition to the phonetic functions, there are a series of distance functions
which measure the difference between two strings. The functions include:
* cosine_distance(,)
* fuzzy_score(,)
* hamming_distance (,)
* jaccard_distance (,)
* jaro_distance (,)
* levenshtein_distance (,)
* longest_common_substring_distance(,)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: how to release allocated ByteBuf which steps across two threads
I also think this is a common problem to the case that the receiver has no chance to sent out a ack reply, maybe it died, causing the query to exception over. Then it will cause the allocator thread’s cleanup method to complain about the memory leak as the sender thread’s exception solving logic to release the ByteBuf maybe happed behind the allocator thread. On Thu, Jun 21, 2018 at 8:51 AM weijie tong wrote: > Hi Parth: > > Thanks for your reply. Your detail description explain that problem > clearly. This problem is not a common case. The bloom filter has not been > sent out while the query has completed. I meet this exception while open > the bloom filter option to run all the join related test cases, then it > happen at TestHashJoin.simpleEqualityJoin() . Btw, the BloomFilter was > sent out through the data tunnel not the control one. To partitioned > broadcast , the bloom filter will send out from each HashJoin node to the > foreman node . The foreman node will wait for all the bloom filter which it > known at the plan stage to come until the timeout occur. Once the foreman > node received all the bloom filter ,it will aggregate them then broadcast > them to all the probe side scan nodes. The design purpose is that all the > origin flow will not blocked by the runtime bloom filter flow . The bloom > filter sending, receiving , applying behaviors are all async ,just a > helpful behavior to the original execution flow. > > > First, not all the HashJoin scenarios is possible to push down the > join predicate such as the both sides has similar row numbers. I will add > some check according the cost at the plan stage to prevent this happen so > the exception scenario will happen less. > > Send, I think the exception scenario still has to prevent to let the > system robust. Your suggestion to add a synchronization between (3) ,(4) > and (6) is good. But the question is that the corresponding receiving side > has completed, it has no chance to give a reply ack. Maybe some other > special timeout Ack was needed to take the lost role to let the Thread1 to > wait while the sending out behavior failed. To this test case , the > hash join node is the last fragment, and it has few data to complete its > query. > > As normal execution flow has worked out, I will share the dev branch > soon by fix some trivial things. Still need suggestions to this problem. > > > > On Thu, Jun 21, 2018 at 6:44 AM Parth Chandra wrote: > >> Hi Weijie >> >> It would also help to understand the flow of control that your design >> uses. I've put a screenshot of a query profile here : >> >> https://docs.google.com/document/d/1DgAbGovEWV6rZ4GvioJz5Twe_m5o1ADoBpbqAzqa_aU/edit?usp=sharing >> >> Looking at the subset under [ Hash Join 06-01 ], can you annotate >> and/or >> explain how you see the control messages flowing? Also, are you using the >> control channel to send the bloom filter? >> >> Parth >> >> On Wed, Jun 20, 2018 at 3:28 PM, Parth Chandra wrote: >> >> > Hi Weijie, >> > This is a tricky problem. So let me first summarize how this should be >> > behaving - >> > >> > Thread 1 | Thread 2 >> > ---+ >> > -- >> > 1) Allocate DrillBuf| >> > 2) Pass memory to RPC layer | get reference to DrillBuf >> > (refcount == 2) >> > 3) | queue up the send (async) >> > 4) | Send and release DrillBuf >> > (refcount == 1) >> > 5) Continue to end of query | >> > 6) Cleanup (release DrillBuf) | >> > 7) Close Allocator (refcount of | >> > DrillBuf *must* be zero) | >> > >> > In your case, steps 3 and 4 are occurring after step 7 which is natural >> > since the RPC send is async, but that is what we have to prevent. The >> only >> > way to do that is to have some synchronization between steps (3), (4), >> and >> > (6) such that (6) only happens after (4). With RPC the way to do so is >> to >> > require an ack. >> > >> > >> > Thread 1 | Thread 2 (Netty) >> > | Thread 3 (foreman) >> > ---+ >> > + >> > 1)Allocate DrillBuf| >> > | >> > 2)Pass memory to RPC layer | get reference to DrillBuf >> > (refcount == 2)| >> > 3) | queue up the send (async) >> > | >> > 4) | Send and release DrillBuf >> > (refcount == 1)| >> > 4.1) | >> > | Recv msg, send back Ack (The RPC layer >> >| >> > |automatically does this) >> > 4.2) Check if Ack received| >> > 5)Continue to end of query | >> > 6)Cleanup
Re: how to release allocated ByteBuf which steps across two threads
Hi Parth: Thanks for your reply. Your detail description explain that problem clearly. This problem is not a common case. The bloom filter has not been sent out while the query has completed. I meet this exception while open the bloom filter option to run all the join related test cases, then it happen at TestHashJoin.simpleEqualityJoin() . Btw, the BloomFilter was sent out through the data tunnel not the control one. To partitioned broadcast , the bloom filter will send out from each HashJoin node to the foreman node . The foreman node will wait for all the bloom filter which it known at the plan stage to come until the timeout occur. Once the foreman node received all the bloom filter ,it will aggregate them then broadcast them to all the probe side scan nodes. The design purpose is that all the origin flow will not blocked by the runtime bloom filter flow . The bloom filter sending, receiving , applying behaviors are all async ,just a helpful behavior to the original execution flow. First, not all the HashJoin scenarios is possible to push down the join predicate such as the both sides has similar row numbers. I will add some check according the cost at the plan stage to prevent this happen so the exception scenario will happen less. Send, I think the exception scenario still has to prevent to let the system robust. Your suggestion to add a synchronization between (3) ,(4) and (6) is good. But the question is that the corresponding receiving side has completed, it has no chance to give a reply ack. Maybe some other special timeout Ack was needed to take the lost role to let the Thread1 to wait while the sending out behavior failed. To this test case , the hash join node is the last fragment, and it has few data to complete its query. As normal execution flow has worked out, I will share the dev branch soon by fix some trivial things. Still need suggestions to this problem. On Thu, Jun 21, 2018 at 6:44 AM Parth Chandra wrote: > Hi Weijie > > It would also help to understand the flow of control that your design > uses. I've put a screenshot of a query profile here : > > https://docs.google.com/document/d/1DgAbGovEWV6rZ4GvioJz5Twe_m5o1ADoBpbqAzqa_aU/edit?usp=sharing > > Looking at the subset under [ Hash Join 06-01 ], can you annotate and/or > explain how you see the control messages flowing? Also, are you using the > control channel to send the bloom filter? > > Parth > > On Wed, Jun 20, 2018 at 3:28 PM, Parth Chandra wrote: > > > Hi Weijie, > > This is a tricky problem. So let me first summarize how this should be > > behaving - > > > > Thread 1 | Thread 2 > > ---+ > > -- > > 1) Allocate DrillBuf| > > 2) Pass memory to RPC layer | get reference to DrillBuf > > (refcount == 2) > > 3) | queue up the send (async) > > 4) | Send and release DrillBuf > > (refcount == 1) > > 5) Continue to end of query | > > 6) Cleanup (release DrillBuf) | > > 7) Close Allocator (refcount of | > > DrillBuf *must* be zero) | > > > > In your case, steps 3 and 4 are occurring after step 7 which is natural > > since the RPC send is async, but that is what we have to prevent. The > only > > way to do that is to have some synchronization between steps (3), (4), > and > > (6) such that (6) only happens after (4). With RPC the way to do so is to > > require an ack. > > > > > > Thread 1 | Thread 2 (Netty) > > | Thread 3 (foreman) > > ---+ > > + > > 1)Allocate DrillBuf| > > | > > 2)Pass memory to RPC layer | get reference to DrillBuf > > (refcount == 2)| > > 3) | queue up the send (async) > > | > > 4) | Send and release DrillBuf > > (refcount == 1)| > > 4.1) | > > | Recv msg, send back Ack (The RPC layer > >| > > |automatically does this) > > 4.2) Check if Ack received| > > 5)Continue to end of query | > > 6)Cleanup (release DrillBuf) | > > 7)Close Allocator (refcount of | > > DrillBuf *must* be zero) | > > > > Note that (4.2) does not have to complete before (5), only before (6) for > > the memory to be released. > > > > One question I have is how the query completed without the Bloom Filter > > reaching its destination. How does the destination fragment know when it > > has to wait for the Bloom Filter? I suspect this may be more > > complicated than it appears at first glance. > > > > Not sure if this helps narrow it down. If you
Re: how to release allocated ByteBuf which steps across two threads
Hi Weijie It would also help to understand the flow of control that your design uses. I've put a screenshot of a query profile here : https://docs.google.com/document/d/1DgAbGovEWV6rZ4GvioJz5Twe_m5o1ADoBpbqAzqa_aU/edit?usp=sharing Looking at the subset under [ Hash Join 06-01 ], can you annotate and/or explain how you see the control messages flowing? Also, are you using the control channel to send the bloom filter? Parth On Wed, Jun 20, 2018 at 3:28 PM, Parth Chandra wrote: > Hi Weijie, > This is a tricky problem. So let me first summarize how this should be > behaving - > > Thread 1 | Thread 2 > ---+ > -- > 1) Allocate DrillBuf| > 2) Pass memory to RPC layer | get reference to DrillBuf > (refcount == 2) > 3) | queue up the send (async) > 4) | Send and release DrillBuf > (refcount == 1) > 5) Continue to end of query | > 6) Cleanup (release DrillBuf) | > 7) Close Allocator (refcount of | > DrillBuf *must* be zero) | > > In your case, steps 3 and 4 are occurring after step 7 which is natural > since the RPC send is async, but that is what we have to prevent. The only > way to do that is to have some synchronization between steps (3), (4), and > (6) such that (6) only happens after (4). With RPC the way to do so is to > require an ack. > > > Thread 1 | Thread 2 (Netty) > | Thread 3 (foreman) > ---+ > + > 1)Allocate DrillBuf| > | > 2)Pass memory to RPC layer | get reference to DrillBuf > (refcount == 2)| > 3) | queue up the send (async) > | > 4) | Send and release DrillBuf > (refcount == 1)| > 4.1) | > | Recv msg, send back Ack (The RPC layer >| > |automatically does this) > 4.2) Check if Ack received| > 5)Continue to end of query | > 6)Cleanup (release DrillBuf) | > 7)Close Allocator (refcount of | > DrillBuf *must* be zero) | > > Note that (4.2) does not have to complete before (5), only before (6) for > the memory to be released. > > One question I have is how the query completed without the Bloom Filter > reaching its destination. How does the destination fragment know when it > has to wait for the Bloom Filter? I suspect this may be more > complicated than it appears at first glance. > > Not sure if this helps narrow it down. If you can share a dev branch we > can help take a look. > > > > On Tue, Jun 19, 2018 at 8:35 PM, weijie tong > wrote: > >> HI: >>I faced a complicated problem by releasing the BloomFilter's direct >> memory at some special cases. Hope someone could give some advices. >> >>Say, one join node sends out BloomFilter to the foreman >> node(TestHashJoin.simpleEqualityJoin() ) . The sending thread is netty's >> BitClient. The BloomFilter's direct memory is allocated by another thread >> allocator (i.e. the HashJoin fragment's allocator). Once the fragment >> completes quickly. Then its corresponding close logic will check the >> allocator's memory assignment. But the async sender thread has not sent >> out >> the BloomFilter to release the corresponding direct ByteBuffer as the >> query >> has completed quickly , the wire has closed. Then the corresponding >> fragment's close logic will throw exception to complain about the memory >> leak. >> >> So I want to know how to release the allocated direct ByteBuffer at >> such case . >> >> >>The exception is : >> >> [Error Id: 0042b168-8728-4367-b461-653837c3a276 on 10.15.235.86:31010] >> at >> org.apache.drill.common.exceptions.UserException$Builder. >> build(UserException.java:633) >> ~[classes/:na] >> at >> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFin >> alState(FragmentExecutor.java:359) >> [classes/:na] >> at >> org.apache.drill.exec.work.fragment.FragmentExecutor.cleanup >> (FragmentExecutor.java:214) >> [classes/:na] >> at >> org.apache.drill.exec.work.fragment.FragmentExecutor.run(Fra >> gmentExecutor.java:325) >> [classes/:na] >> at >> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleanin >> gRunnable.java:38) >> [classes/:na] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >> Executor.java:1149) >> [na:1.8.0_161] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >> lExecutor.java:624) >> [na:1.8.0_161] >> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161] >> Caused by: java.lang.IllegalStateException: Allocator[frag:0:0] closed >> with >> outstanding buffers allocated (1).
Re: how to release allocated ByteBuf which steps across two threads
Hi Weijie, This is a tricky problem. So let me first summarize how this should be behaving - Thread 1 | Thread 2 ---+-- 1) Allocate DrillBuf| 2) Pass memory to RPC layer | get reference to DrillBuf (refcount == 2) 3) | queue up the send (async) 4) | Send and release DrillBuf (refcount == 1) 5) Continue to end of query | 6) Cleanup (release DrillBuf) | 7) Close Allocator (refcount of | DrillBuf *must* be zero) | In your case, steps 3 and 4 are occurring after step 7 which is natural since the RPC send is async, but that is what we have to prevent. The only way to do that is to have some synchronization between steps (3), (4), and (6) such that (6) only happens after (4). With RPC the way to do so is to require an ack. Thread 1 | Thread 2 (Netty) | Thread 3 (foreman) ---++ 1)Allocate DrillBuf| | 2)Pass memory to RPC layer | get reference to DrillBuf (refcount == 2)| 3) | queue up the send (async) | 4) | Send and release DrillBuf (refcount == 1)| 4.1) | | Recv msg, send back Ack (The RPC layer | |automatically does this) 4.2) Check if Ack received| 5)Continue to end of query | 6)Cleanup (release DrillBuf) | 7)Close Allocator (refcount of | DrillBuf *must* be zero) | Note that (4.2) does not have to complete before (5), only before (6) for the memory to be released. One question I have is how the query completed without the Bloom Filter reaching its destination. How does the destination fragment know when it has to wait for the Bloom Filter? I suspect this may be more complicated than it appears at first glance. Not sure if this helps narrow it down. If you can share a dev branch we can help take a look. On Tue, Jun 19, 2018 at 8:35 PM, weijie tong wrote: > HI: >I faced a complicated problem by releasing the BloomFilter's direct > memory at some special cases. Hope someone could give some advices. > >Say, one join node sends out BloomFilter to the foreman > node(TestHashJoin.simpleEqualityJoin() ) . The sending thread is netty's > BitClient. The BloomFilter's direct memory is allocated by another thread > allocator (i.e. the HashJoin fragment's allocator). Once the fragment > completes quickly. Then its corresponding close logic will check the > allocator's memory assignment. But the async sender thread has not sent out > the BloomFilter to release the corresponding direct ByteBuffer as the query > has completed quickly , the wire has closed. Then the corresponding > fragment's close logic will throw exception to complain about the memory > leak. > > So I want to know how to release the allocated direct ByteBuffer at > such case . > > >The exception is : > > [Error Id: 0042b168-8728-4367-b461-653837c3a276 on 10.15.235.86:31010] > at > org.apache.drill.common.exceptions.UserException$ > Builder.build(UserException.java:633) > ~[classes/:na] > at > org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState( > FragmentExecutor.java:359) > [classes/:na] > at > org.apache.drill.exec.work.fragment.FragmentExecutor. > cleanup(FragmentExecutor.java:214) > [classes/:na] > at > org.apache.drill.exec.work.fragment.FragmentExecutor.run( > FragmentExecutor.java:325) > [classes/:na] > at > org.apache.drill.common.SelfCleaningRunnable.run( > SelfCleaningRunnable.java:38) > [classes/:na] > at > java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1149) > [na:1.8.0_161] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:624) > [na:1.8.0_161] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161] > Caused by: java.lang.IllegalStateException: Allocator[frag:0:0] closed > with > outstanding buffers allocated (1). > Allocator(frag:0:0) 400/16777216/47664448/30357913941 > (res/actual/peak/limit) > child allocators: 0 > ledgers: 1 > ledger[6268] allocator: frag:0:0), isOwning: true, size: 16777216, > references: 1, life: 505919927431943..0, allocatorManager: [6050, life: > 505919927378312..0] holds 2 buffers. > DrillBuf[10198], udle: [6051 0..16777216] > DrillBuf[10208], udle: [6051 0..16777216] > reservations: 0 > > at org.apache.drill.exec.memory.BaseAllocator.close( > BaseAllocator.java:503) > ~[classes/:na] > at > org.apache.drill.exec.ops.FragmentContextImpl.suppressingClose( > FragmentContextImpl.java:484) > ~[classes/:na] > at >
[jira] [Created] (DRILL-6518) DESCRIBE command on Drill created parquet table does not return results
Khurram Faraaz created DRILL-6518:
-
Summary: DESCRIBE command on Drill created parquet table does not
return results
Key: DRILL-6518
URL: https://issues.apache.org/jira/browse/DRILL-6518
Project: Apache Drill
Issue Type: Bug
Components: Storage - Parquet
Affects Versions: 1.14.0
Reporter: Khurram Faraaz
Attachments: 0_0_0.parquet, item.drill.parquet_metadata
Describe command on a Drill (1.14.0) created parquet table, does not return the
table description.
Parquet file and parquet metadata cache file for item table is attached here,
it has the details of column types in the metadata cache file.
{noformat}
Apache Drill 1.14.0-SNAPSHOT
commit : b447260e49dc4a8c906f5b310c037fe6dd77166f
{noformat}
{noformat}
// DESCRIBE commands returns no information about the table.
0: jdbc:drill:schema=dfs.tpcds_sf1_parquet_vi> describe
dfs.`/drill/testdata/tpcds_sf1/parquet/item`;
+--++--+
| COLUMN_NAME | DATA_TYPE | IS_NULLABLE |
+--++--+
+--++--+
No rows selected (0.221 seconds)
0: jdbc:drill:schema=dfs.tpcds_sf1_parquet_vi> refresh table metadata
dfs.`/drill/testdata/tpcds_sf1/parquet/item`;
+---+--+
| ok | summary |
+---+--+
| true | Successfully updated metadata for table
/drill/testdata/tpcds_sf1/parquet/item. |
+---+--+
1 row selected (0.173 seconds)
0: jdbc:drill:schema=dfs.tpcds_sf1_parquet_vi> describe
dfs.`/drill/testdata/tpcds_sf1/parquet/item`;
+--++--+
| COLUMN_NAME | DATA_TYPE | IS_NULLABLE |
+--++--+
+--++--+
No rows selected (0.229 seconds)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [jira] [Created] (DRILL-6514) Document pcap format plug-in options
On the master branch I am not seeing the 'extensions' class variable in the reference chain shown in the Jackson error message either. There is an extensions parameter in the constructor of the EasyFormatPlugin [1] which is the base class of PcapFormatPlugin but I don't think Jackson is complaining about that. Was this introduced in an earlier version of Drill and later removed ? Can someone familiar with this format plugin help Ted ? [1] https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/easy/EasyFormatPlugin.java#L78 On Mon, Jun 18, 2018 at 9:34 PM, Ted Dunning wrote: > What does it take to fix this in the code? > > How does the extensions parameter get into the plugin? > > On Mon, Jun 18, 2018 at 10:07 PM Veera Naranammalpuram (JIRA) < > j...@apache.org> wrote: > > > ... > > > > The pcap format plug in does not accept the "extensions" parameter. > > >
