Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate JMX connector to new APIs #511

Closed
wants to merge 1 commit into from

Conversation

takezoe
Copy link
Member

@takezoe takezoe commented Mar 20, 2019

No description provided.

Copy link
Member

@findepi findepi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@takezoe thank you for your contribution!

Fix deprecation warning in jmx plugin

I would change the commit message to reflect that you're migrating the JMX connector to the new APIs.

@martint i am sorry, i didn't follow the API changes. Please review.

import io.prestosql.spi.connector.Constraint;
import io.prestosql.spi.connector.SchemaTableName;
import io.prestosql.spi.connector.SchemaTablePrefix;
import io.prestosql.spi.connector.*;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not use star imports.
Hopefully importing https://github.com/airlift/codestyle into Intellij should get you the right configuration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Fixed it.

@takezoe takezoe changed the title Fix deprecation warning in jmx plugin Migrate JMX connector to new APIs Mar 20, 2019
@takezoe
Copy link
Member Author

takezoe commented Mar 20, 2019

@findepi Thanks for your review! I fixed code and updated the title of this pull request.

Currently some test cases are commented out because it seems that there is no way to give predicate to SplitManager without deprecated version of getSplits() method. Actually, I'm not sure how I can port this part to new APIs.

// for (Node node : nodes) {
// String nodeIdentifier = node.getNodeIdentifier();
//
// // TODO Is there any way to give predicate to SplitManager without deprecated version of getSplits()?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new API doesn't yet support pushing down predicates. It's something we're adding as part of #18. We'll add a version of the API that takes a Constraint object like getTableLayout does today to ease migration. We should probably wait to complete and merge this PR until that gets in (which will happen soon), otherwise, we're removing existing features for this connector.

Copy link
Member Author

@takezoe takezoe Mar 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation! I understand it isn't a time to migrate connectors yet. I'm waiting for Constraint to be added.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@takezoe, with this, you should be able to complete the migration of this connector: #541.

@takezoe takezoe changed the title Migrate JMX connector to new APIs [WIP] Migrate JMX connector to new APIs Mar 22, 2019
@martint
Copy link
Member

martint commented Apr 2, 2019

@takezoe, #541 is merged, so you should be able to rebase this PR and implement the missing functionality now.

@takezoe
Copy link
Member Author

takezoe commented Apr 2, 2019

Thanks! I'm going to resume working on this pull request.

@takezoe takezoe force-pushed the fix-jmx-warning branch 3 times, most recently from ab2ed22 to c04d402 Compare April 13, 2019 08:04
@takezoe takezoe changed the title [WIP] Migrate JMX connector to new APIs Migrate JMX connector to new APIs Apr 13, 2019
public static class Node
{
private String identifier;
private HostAddress address;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these fields should be private final.

Optional<ConstraintApplicationResult<ConnectorTableHandle>> result = metadata.applyFilter(handle, new Constraint(TupleDomain.all()));

assertTrue(result.isPresent());
assertTrue(((JmxTableHandle) result.get().getHandle()).getNodes().size() == 3);
Copy link
Member

@ebyhr ebyhr Apr 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to use assertEquals when we check two values. L138 is also the same.


private static JmxTableHandle.Node createTestingNode(String hostname)
{
return new JmxTableHandle.Node(hostname, HostAddress.fromString(format("%s:8080", hostname)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HostAddress.fromParts is simpler than concating hostname and port.

return new JmxTableHandle.Node(hostname, HostAddress.fromParts(hostname, 8080));

.map(node -> new JmxSplit(ImmutableList.of(node.getHostAndPort())))
.collect(toList());
List<ConnectorSplit> splits = tableHandle.getNodes().stream()
.map(node -> new JmxSplit(ImmutableList.of(node.getAddress()))).collect(toList());
Copy link
Member

@ebyhr ebyhr Apr 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move .collect(toList()); to next line.

Also, we can use .collect(toImmutableList()); and then change L40 to

return new FixedSplitSource(splits);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move .collect(toList()); to next line.

Do we have a specific regulation about putting new lines? Actually, I have a similar code in JmxMetadata as follows. I'm wondering if I have to put new lines before .map and .collect.

private List<JmxTableHandle.Node> getAllNodes()
{
    return nodeManager.getAllNodes().stream().map(node -> new JmxTableHandle.Node(node.getNodeIdentifier(), node.getHostAndPort())).collect(toList());
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the statement is simple, one line is fine. When you break a line after .stream(), subsequent each operations should be independent line as original code was. (There's no 'specific' regulation as far as I know).

The getAllNodes looks little long for one line and there's only one statement in the method, so putting new lines looks reasonable to me.

ConnectorSession session,
ConnectorSplit split,
ConnectorTableHandle table,
List<? extends ColumnHandle> columns)
Copy link
Member

@ebyhr ebyhr Apr 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks just fixing style, but the commit title is Fix warning in JmxRecordSetProvider. What is the waring message (line length)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember. Let me revert this change.

})
.collect(toList());

JmxTableHandle newTaleHandle = new JmxTableHandle(tableHandle.getTableName(), tableHandle.getObjectNames(), tableHandle.getColumnHandles(), tableHandle.isLiveData(), nodes);
Copy link
Member

@ebyhr ebyhr Apr 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo newTaleHandlenewTableHandle

@takezoe takezoe force-pushed the fix-jmx-warning branch 2 times, most recently from 3cc894c to 8967050 Compare April 14, 2019 06:30
@takezoe
Copy link
Member Author

takezoe commented Apr 15, 2019

@martint I finished to migrate the JMX connector node selection pushdown to Metadata.applyFilter. Can you take a look?

Copy link
Member

@martint martint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! That's a step in the right direction, but as a I mentioned in the comment above, it'd be better to hold on to the filter in the table handle instead of the list of filtered nodes (which can be large for large installations). and filter them at the point splits are generated.


@JsonCreator
public JmxTableHandle(
@JsonProperty("tableName") SchemaTableName tableName,
@JsonProperty("objectNames") List<String> objectNames,
@JsonProperty("columnHandles") List<JmxColumnHandle> columnHandles,
@JsonProperty("liveData") boolean liveData,
@JsonProperty("addresses") List<HostAddress> addresses)
@JsonProperty("nodes") List<Node> nodes)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why hold on to the list of nodes in the TableHandle? I'd be better to just hold on to the predicate and filter them out during split generation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my understanding, to hold the predicate ( TupleDomain or Map<ColumnHandle, Domain>) in the TableHandle, we need to make all classes held in the ValueSet serializable to JSON. Is this correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I didn't know TupleDomain is always JSON serializable. I fixed to hold TupleDomain in TableHandle instead of the list of node.

@Override
public ConnectorTableProperties getTableProperties(ConnectorSession session, ConnectorTableHandle table)
{
return new ConnectorTableProperties(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can use the no-args constructor, which does the same thing

@electrum electrum self-requested a review April 22, 2019 22:10
@martint
Copy link
Member

martint commented Apr 30, 2019

@takezoe, can you rebase on master and remove the merge commits? They are confusing github and it's not displaying the actual differences with respect to the base commit.

@takezoe
Copy link
Member Author

takezoe commented May 1, 2019

Sure, I rebased on master branch without merge commits.

return ImmutableList.of(new ConnectorTableLayoutResult(layout, constraint.getSummary()));
}
JmxTableHandle tableHandle = (JmxTableHandle) handle;
TupleDomain<ColumnHandle> predicate = constraint.getSummary();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

applyFilter can get called multiple times throughout the optimization process. Connectors need to ensure that they "remember" the result of previous applications. Also, if applying the filter did not have any effect, the method needs to return Optional.empty(). Otherwise, the optimizer may loop forever.

See https://github.com/prestosql/presto/blob/master/presto-base-jdbc/src/main/java/io/prestosql/plugin/jdbc/JdbcMetadata.java#L86 for an example.

return new ConnectorTableLayout(handle);
JmxTableHandle newTableHandle = new JmxTableHandle(tableHandle.getTableName(), tableHandle.getObjectNames(), tableHandle.getColumnHandles(), tableHandle.isLiveData(), predicate);

return Optional.of(new ConstraintApplicationResult(newTableHandle, predicate));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the connector guarantees the results are going to satisfy the constraint, it's not necessary to return the predicate in the ConstraintApplicationResult. It can just indicate TupleDomain.ALL.

@takezoe
Copy link
Member Author

takezoe commented May 2, 2019

@martint Thanks for your review again. Fixed to return Option.empty if JmxTableHandle has a exact same constraint. Also now JmxTableHandle holds only node column filter and others are passed to ConstraintApplicationResult as remainingFilter to exclude predicates which are processed by the connector.

Copy link
Member

@martint martint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay. This looks great. Just a few minor comments, mostly around unrelated changes.

Can you squash all commits? I'll merge it then.


//TODO is there a better way to get the node column?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry. Reverted.

Optional<JmxColumnHandle> nodeColumnHandle = tableHandle.getColumnHandles().stream()
.filter(jmxColumnHandle -> jmxColumnHandle.getColumnName().equals(NODE_COLUMN_NAME))
.findFirst();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated formatting change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. Reverted too.

.addEquivalentGroup(
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("name"), COLUMNS, false),
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("name"), COLUMNS, false))
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("nameX"), COLUMNS, true, TupleDomain.all()),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the name change here?

Copy link
Member Author

@takezoe takezoe May 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is diff magic. I didn't change the name, just added new arguments. "name" patterns are coverd by preceding 2 equivalent groups.

.addEquivalentGroup(
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("nameX"), COLUMNS, false),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the name change here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Fix warning in JmxRecordSetProvider

Removed unused import statements

Migrate node column pushdown to applyFilter

Fix compilation error

Fix JmxTableHandle to have all nodes initially then filter them at applyFilter

Add tests for JmxMetadata#applyFilter()

Review feedback

Add TupleDomain to JmxTableHandle

Fix JmxMetadata.getTableProperties to use no-args constructor

Fix compilation error

Return empty from applyFilter if TableHandle has same constraint

Split TupleDomain to node column and others

Fix Json property name and error message of nodeFilter

Post review feedback
@takezoe
Copy link
Member Author

takezoe commented May 21, 2019

@martint Thanks for your comment! Fixed and squashed.

@martint
Copy link
Member

martint commented May 21, 2019

Merged. Thanks for your contribution!

@martint martint closed this May 21, 2019
@takezoe takezoe deleted the fix-jmx-warning branch May 22, 2019 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

5 participants