[
https://issues.apache.org/jira/browse/DRILL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247961#comment-16247961
]
ASF GitHub Bot commented on DRILL-5771:
---------------------------------------
Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/1014
@ilooner, there are two phases of issues. The problem is in the planner,
but we've been talking about serialization out to the workers.
Here, we can learn from the work Arina did with dynamic UDFs, especially in
the synchronization aspects as it has potential challenges similar to what we
have here.
Let's walk through the lifecycle.
* User A defines a storage plugin config, call it P.
* User B else runs a query Q that references P.
* At the same time, user A changes P to P'.
* Query Q is distributed to nodes.
* At the same time, user A changes P again to produce P''.
This is a classic distributed system synchronization problem. As we
discussed, once the query is planned, the contents of the plugin definition are
serialized as part of the physical plan for each fragment. As a result we
"freeze" the contents of P at the time of serialization.
The problem that Arina seems to be describing is during planning. Rather
than taking a copy of P at some fixed point in time, then always using that
copy; we seem to be holding a named reference to P. This introduces the obvious
synchronization issues.
So, what we should do is, once a query resolves P, the query takes a copy
and uses that copy for the rest of query planning and execution.
This resolves race conditions by saying that a query (on all nodes) uses
the version of the plugin definition that existed at the moment that the
reference to the plugin definition was first resolved by that query. The query
will be oblivious to all subsequent updates.
Since plugin definition is done as part of workspace and table definition
in Calcite, this is likely to be a tricky change; it is not clear that Calcite
offers a per-query context to hold such information. Arina probably can offer
advice on this front.
> Fix serDe errors for format plugins
> -----------------------------------
>
> Key: DRILL-5771
> URL: https://issues.apache.org/jira/browse/DRILL-5771
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.11.0
> Reporter: Arina Ielchiieva
> Assignee: Arina Ielchiieva
> Priority: Minor
> Fix For: 1.12.0
>
>
> Create unit tests to check that all storage format plugins can be
> successfully serialized / deserialized.
> Usually this happens when query has several major fragments.
> One way to check serde is to generate physical plan (generated as json) and
> then submit it back to Drill.
> One example of found errors is described in the first comment. Another
> example is described in DRILL-5166.
> *Serde issues:*
> 1. Could not obtain format plugin during deserialization
> Format plugin is created based on format plugin configuration or its name.
> On Drill start up we load information about available plugins (its reloaded
> each time storage plugin is updated, can be done only by admin).
> When query is parsed, we try to get plugin from the available ones, it we can
> not find one we try to [create
> one|https://github.com/apache/drill/blob/3e8b01d5b0d3013e3811913f0fd6028b22c1ac3f/exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSystemPlugin.java#L136-L144]
> but on other query execution stages we always assume that [plugin exists
> based on
> configuration|https://github.com/apache/drill/blob/3e8b01d5b0d3013e3811913f0fd6028b22c1ac3f/exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSystemPlugin.java#L156-L162].
> For example, during query parsing we had to create format plugin on one node
> based on format configuration.
> Then we have sent major fragment to the different node where we used this
> format configuration we could not get format plugin based on it and
> deserialization has failed.
> To fix this problem we need to create format plugin during query
> deserialization if it's absent.
>
> 2. Absent hash code and equals.
> Format plugins are stored in hash map where key is format plugin config.
> Since some format plugin configs did not have overridden hash code and
> equals, we could not find format plugin based on its configuration.
> 3. Named format plugin usage
> Named format plugins configs allow to get format plugin by its name for
> configuration shared among all drillbits.
> They are used as alias for pre-configured format plugiins. User with admin
> priliges can modify them at runtime.
> Named format plugins configs are used instead of sending all non-default
> parameters of format plugin config, in this case only name is sent.
> Their usage in distributed system may cause raise conditions.
> For example,
> 1. Query is submitted.
> 2. Parquet format plugin is created with the following configuration
> (autoCorrectCorruptDates=>true).
> 3. Seralized named format plugin config with name as parquet.
> 4. Major fragment is sent to the different node.
> 5. Admin has changed parquet configuration for the alias 'parquet' on all
> nodes to autoCorrectCorruptDates=>false.
> 6. Named format is deserialized on the different node into parquet format
> plugin with configuration (autoCorrectCorruptDates=>false).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
