[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122381#comment-15122381 ] Josh Elser commented on CALCITE-642: So this is what I'm thinking: * Remove all dropwizard API use in Avatica directly, create my own interfaces ala "avatica-metrics" * Implement interfaces in an "avatica-metrics-dropwizard-3" (or something -- need to figure out what/if-at-all is their compat statement) * Have calcite-avatica create two (shaded) artifacts: "calcite-avatica.jar" and "calcite-avatica-without-metrics.jar" (could also do a with-metrics instead of without-metrics but I'm being selfish and hoping the without-metrics jar would be less common) For those running in an AppServer (or some shared environment w/o classpath isolation), they can use the without-metrics jar and provide the version they want. We would also be able to provide bindings for other systems natively (if necessary). Hopefully, the common case would still be the single calcite-avatica.jar, but we wouldn't screw over those whose needs aren't satisfied. > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[
https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122284#comment-15122284
]
Josh Elser commented on CALCITE-642:
Thanks for taking a look, Julian.
bq. Change the commit description to make clear you're adding to Avatica
*server*. We don't need dependency bloat in the client.
So, this isn't entirely true. We have some code which is only intended to run
in the server, but lives in the "client" package, e.g. {{JsonHandler}} handles
the serialization into POJOs. The dropwizard-metrics artifact itself is only
110KB in size, ~100classes and the only provided reporter is an slf4j one
(suddenly the slf4j work becomes more important). Long term, I think having the
ability to use this metrics instrumentation to measure things in the client is
valuable as well (but is presently left as a "todo"). Looks like the
calcite-avatica jar is at ~3.5MB with these changes.
Is including this dependency in the calcite-avatica a deal-breaker for you?
Restructuring stuff for avatica has been on my radar (notably the splitting up
of Service and the POJOs), but I didn't want to try to tackle both of these at
once.
bq. Add a small section to http://calcite.apache.org/docs/avatica_overview.html
and add the package to the "structure" section
Ahh, thanks for the reminder. I meant to write up some docs for users too.
bq. Move the version number in pom.xml into the properties list (consistent
with what I did in CALCITE-999)
Will do.
> Avatica server metrics
> --
>
> Key: CALCITE-642
> URL: https://issues.apache.org/jira/browse/CALCITE-642
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Nick Dimiduk
>Assignee: Josh Elser
> Labels: avatica
> Fix For: next
>
>
> Along the same lines as CALCITE-641, avatica server should track some basic
> metrics. We can expose them through a "standard" API (such as Hadoop metrics,
> or Dropwizard metrics), and include them on some interval in the service log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122301#comment-15122301 ] Josh Elser commented on CALCITE-642: bq. I don't want to be a jerk about this Not at all! I'm just trying to make sure I understand the scope of the objection. bq. The client might be used in an environment (say an app server) that has an incompatible version of Dropwizard Let me play with this, we might be able to work around this the same way we did for protobuf (relocating the classes in the shaded jar). This is a bit dirtier since it's not self-contained like protobuf was (we expect users to have some interactions). Let me brainstorm some ideas. > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-642) Avatica server metrics
[ https://issues.apache.org/jira/browse/CALCITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122230#comment-15122230 ] Julian Hyde commented on CALCITE-642: - Very nice work. A few things: * Change the commit description to make clear you're adding to Avatica *server*. We don't need dependency bloat in the client. * Move the version number in pom.xml into the properties list (consistent with what I did in CALCITE-999) * Add a small section to http://calcite.apache.org/docs/avatica_overview.html and add the package to the "structure" section I ran the extended test suite, and everything looks great. So +1 to commit when you've fixed the above. > Avatica server metrics > -- > > Key: CALCITE-642 > URL: https://issues.apache.org/jira/browse/CALCITE-642 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser > Labels: avatica > Fix For: next > > > Along the same lines as CALCITE-641, avatica server should track some basic > metrics. We can expose them through a "standard" API (such as Hadoop metrics, > or Dropwizard metrics), and include them on some interval in the service log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1070) Upgrade to new Apache logo
Julian Hyde created CALCITE-1070: Summary: Upgrade to new Apache logo Key: CALCITE-1070 URL: https://issues.apache.org/jira/browse/CALCITE-1070 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Upgrade web site to new Apache logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122288#comment-15122288 ] Julian Hyde commented on CALCITE-1062: -- But why add all this new code? Anyone can supply a custom implementation of SqlOperatorTable and use it in the validator. That already works, AFAIK. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122778#comment-15122778 ] Sean Hsuan-Yi Chu commented on CALCITE-1062: That is true for "SqlFunction" only. You could compare the bodies of SqlFunction.deriveType() and SqlOperator.deriveType(). While SqlFunction.deriveType() looks up an overriding operator from SqlOperatorTable, SqlOperator.deriveType() does not. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
