[
https://issues.apache.org/jira/browse/PHOENIX-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298957#comment-14298957
]
James Taylor commented on PHOENIX-1596:
---------------------------------------
Also, more of a question/comment, but why are the two tracing calls (between
the one tracing the scans versus the one tracing the index puts) so different?
No need to call Tracing.childOnServer() and Trace.continueSpan(savedSpan) for
indexing puts? Does that mean that if tracing is turned on and the first thing
that happens is an index update, that tracing won't be turned on (as looking at
Tracing.childOnServer(), that appears to be what it's doing)?
IMO, this likely needs a bit of an API cleanup. Maybe Tracing.childOnServer()
should return an object that contains the prior and new span? Or maybe it's
more clear if we didn't have Tracing.childOnServer(), but just did what it does
inline?
> Setting tracing frequency to ALWAYS on the client side results in too many
> traces
> ---------------------------------------------------------------------------------
>
> Key: PHOENIX-1596
> URL: https://issues.apache.org/jira/browse/PHOENIX-1596
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Attachments: PHOENIX-1596.patch
>
>
> After setting trace collection frequency to always by setting the following
> in hbase-site.xml, I noticed that it created way too many traces in the trace
> table.
> <property>
> <name>phoenix.trace.frequency</name>
> <value>always</value>
> </property>
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 1283 |
> +------------------------------------------+
> 1 row selected (1.104 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 4051 |
> +------------------------------------------+
> 1 row selected (1.058 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 10668 |
> +------------------------------------------+
> 1 row selected (1.105 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 11361 |
> +------------------------------------------+
> 1 row selected (1.046 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 193119 |
> +------------------------------------------+
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 1283 |
> +------------------------------------------+
> 1 row selected (1.104 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 4051 |
> +------------------------------------------+
> 1 row selected (1.058 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 10668 |
> +------------------------------------------+
> 1 row selected (1.105 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 11361 |
> +------------------------------------------+
> 1 row selected (1.046 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> +------------------------------------------+
> | COUNT(1) |
> +------------------------------------------+
> | 193119 |
> +------------------------------------------+
> 1 row selected (6.737 seconds)
> 0: jdbc:phoenix:localhost> select count (*) from system.tracing_stats;
> 15/01/19 17:26:57 WARN client.HConnectionManager$HConnectionImplementation:
> This client just lost it's session with ZooKeeper, closing it. It will be
> recreated next time someone needs it
> Even though the only query that was being executed was the select count(*) to
> get the number of rows in the trace table, it ended up creating way too many
> traces than I had expected.
> On my mac, it in fact ended up killing the local hbase cluster altogether!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
