[
https://issues.apache.org/jira/browse/DRILL-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046038#comment-17046038
]
ASF GitHub Bot commented on DRILL-7578:
---------------------------------------
paul-rogers commented on pull request #1978: DRILL-7578: HDF5 Metadata Queries
Fail with Large Files
URL: https://github.com/apache/drill/pull/1978#discussion_r384867611
##########
File path:
contrib/format-hdf5/src/main/java/org/apache/drill/exec/store/hdf5/HDF5BatchReader.java
##########
@@ -946,7 +990,11 @@ private void writeAttributes(TupleWriter rowWriter,
HDF5DrillMetadata record) {
writeLongColumn(mapWriter, key, (Long) attrib.getValue());
break;
case INT:
- writeIntColumn(mapWriter, key, (Integer) attrib.getValue());
+ try {
+ writeIntColumn(mapWriter, key, (Integer) attrib.getValue());
+ } catch (Exception e) {
+ logger.warn("{} {}", key, attrib);
Review comment:
Is this the right solution? What would cause the exception? If reading 100M
rows, do we want to emit 100M warnings into the log? Will the user understand
why the value in some column is null?
Should we be more selective: catching the (one) exception we want to ignore
and failing for all others?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> HDF5 Metadata Queries Fail with Large Files
> -------------------------------------------
>
> Key: DRILL-7578
> URL: https://issues.apache.org/jira/browse/DRILL-7578
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.18.0
> Reporter: Charles Givre
> Assignee: Charles Givre
> Priority: Major
> Fix For: 1.18.0
>
>
> With large files, Drill runs out of memory when attempting to project large
> datasets in the metadata.
> This PR adds a configuration option which removes the dataset projection from
> metadata queries and fixes this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
