[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018444#comment-17018444 ] Hudson commented on PHOENIX-5634: - ABORTED: Integrated in Jenkins build Phoenix-4.x-HBase-1.4 #372 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.4/372/]) PHOENIX-5634: Use 'phoenix.default.update.cache.frequency' from (yanxinyi: rev 90f92412c3b569b5b3ef56fd514545f94e5881aa) * (add) phoenix-core/src/it/java/org/apache/phoenix/rpc/UpdateCacheConnectionLevelPropIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v6.patch > > Time Spent: 4h 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018394#comment-17018394 ] Hudson commented on PHOENIX-5634: - FAILURE: Integrated in Jenkins build PreCommit-PHOENIX-Build #3328 (See [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3328/]) PHOENIX-5634: Use 'phoenix.default.update.cache.frequency' from (yanxinyi: rev f9948aa3f9fd3c2b2d02afd58fae78b44d0c8bdb) * (add) phoenix-core/src/it/java/org/apache/phoenix/rpc/UpdateCacheConnectionLevelPropIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v6.patch > > Time Spent: 4h 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018377#comment-17018377 ] Hudson commented on PHOENIX-5634: - FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-1.3 #657 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.3/657/]) PHOENIX-5634: Use 'phoenix.default.update.cache.frequency' from (yanxinyi: rev d14c9f8c0f699cb53b04b779ba84864f24984480) * (edit) phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java * (add) phoenix-core/src/it/java/org/apache/phoenix/rpc/UpdateCacheConnectionLevelPropIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v6.patch > > Time Spent: 4h 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018342#comment-17018342 ] Hudson commented on PHOENIX-5634: - SUCCESS: Integrated in Jenkins build Phoenix-4.x-HBase-1.5 #250 (See [https://builds.apache.org/job/Phoenix-4.x-HBase-1.5/250/]) PHOENIX-5634: Use 'phoenix.default.update.cache.frequency' from (yanxinyi: rev 904839167474641a306215009d1b3adc55e83e09) * (add) phoenix-core/src/it/java/org/apache/phoenix/rpc/UpdateCacheConnectionLevelPropIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v6.patch > > Time Spent: 4h 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018341#comment-17018341 ] Xinyi Yan commented on PHOENIX-5634: Thanks for the patch, [~ntshmah]. I just committed your code to 4.x and master branches. > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v3.patch, PHOENIX-5634.master.v4.patch, > PHOENIX-5634.master.v5.patch, PHOENIX-5634.master.v6.patch > > Time Spent: 4h 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018266#comment-17018266 ] Nitesh Maheshwari commented on PHOENIX-5634: Hi [~yanxinyi]/[~ckulkarni] Can we merge this now? 4.x-HBase-1.3 branch: https://builds.apache.org/job/PreCommit-PHOENIX-Build/3314/ Master branch: https://builds.apache.org/job/PreCommit-PHOENIX-Build/3327/ Thanks, Nitesh > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0, 5.1.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 5.1.0, 4.15.1 > > Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch, > PHOENIX-5634.master.v3.patch, PHOENIX-5634.master.v4.patch, > PHOENIX-5634.master.v5.patch, PHOENIX-5634.master.v6.patch > > Time Spent: 4h > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018263#comment-17018263
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991238/PHOENIX-5634.master.v6.patch
against master branch at commit 65ae368b7f72ac138d646dc7e8c00c95cb8d1d5a.
ATTACHMENT ID: 12991238
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3327//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3327//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v3.patch, PHOENIX-5634.master.v4.patch,
> PHOENIX-5634.master.v5.patch, PHOENIX-5634.master.v6.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017443#comment-17017443
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991161/PHOENIX-5634.master.v5.patch
against master branch at commit 05a44ad162181cd63ba6d7ad00a259fa17a6c60c.
ATTACHMENT ID: 12991161
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.join.HashJoinMoreIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.QueryIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3326//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3326//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v3.patch, PHOENIX-5634.master.v4.patch,
> PHOENIX-5634.master.v5.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016471#comment-17016471
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991051/PHOENIX-5634.master.v4.patch
against master branch at commit 52e5e2ae320be9be649188b0208d3b05cbe7bedc.
ATTACHMENT ID: 12991051
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3321//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3321//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v3.patch, PHOENIX-5634.master.v4.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016408#comment-17016408
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991038/PHOENIX-5634.master.v3.patch
against master branch at commit 52e5e2ae320be9be649188b0208d3b05cbe7bedc.
ATTACHMENT ID: 12991038
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3318//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3318//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v3.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016390#comment-17016390
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991026/PHOENIX-5634.4.x-HBase-1.3.v3.patch
against 4.x-HBase-1.3 branch at commit
beb6457086c8e51fc8be5eceb468a1edf8a358b7.
ATTACHMENT ID: 12991026
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3314//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3314//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v2.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016363#comment-17016363
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12991026/PHOENIX-5634.4.x-HBase-1.3.v3.patch
against 4.x-HBase-1.3 branch at commit
beb6457086c8e51fc8be5eceb468a1edf8a358b7.
ATTACHMENT ID: 12991026
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.AlterTableWithViewsIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3315//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3315//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v3.patch,
> PHOENIX-5634.master.v2.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015847#comment-17015847
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12990957/PHOENIX-5634.4.x-HBase-1.3.v2.patch
against 4.x-HBase-1.3 branch at commit
beb6457086c8e51fc8be5eceb468a1edf8a358b7.
ATTACHMENT ID: 12990957
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexSplitForwardScanIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.MaxLookbackIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ContextClassloaderIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3305//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3305//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v1.patch,
> PHOENIX-5634.4.x-HBase-1.3.v2.patch, PHOENIX-5634.master.v1.patch,
> PHOENIX-5634.master.v2.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[
https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015540#comment-17015540
]
Hadoop QA commented on PHOENIX-5634:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12990922/PHOENIX-5634.4.x-HBase-1.3.v1.patch
against 4.x-HBase-1.3 branch at commit
6405839b60c410292c0e2c8cbbdee55d09343bab.
ATTACHMENT ID: 12990922
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.StatsEnabledSplitSystemCatalogIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TenantSpecificViewIndexSaltedIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.MaxLookbackIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3297//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3297//console
This message is automatically generated.
> Use 'phoenix.default.update.cache.frequency' from connection properties at
> query time
> -
>
> Key: PHOENIX-5634
> URL: https://issues.apache.org/jira/browse/PHOENIX-5634
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Nitesh Maheshwari
>Assignee: Nitesh Maheshwari
>Priority: Minor
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-5634.4.x-HBase-1.3.v1.patch,
> PHOENIX-5634.master.v1.patch
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> We have the config 'phoenix.default.update.cache.frequency' which specifies
> the time a client should wait before it refreshes its metadata cache entry
> for a table by fetching the latest metadata from system catalog. This value
> could be set for a table in the following ways (in the following preference
> order):
> # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL
> # Specifying the connection property 'phoenix.default.update.cache.frequency'
> # Using the default 'phoenix.default.update.cache.frequency'
> At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for
> the table and decide based on that value if the latest metadata for a table
> should be fetched from system catalog to update the cache. However, when the
> table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the
> connection property 'phoenix.default.update.cache.frequency' (or the default
> 'phoenix.default.update.cache.frequency' when the connection level property
> is not set) to make that decision. The support for latter is missing - this
> Jira is intended to add that.
> This will aid exiting installations where the tables were created without a
> specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to
> get the latest metadata when referenced. With this support, we will be able
> to reduce the load on system catalog by specifying a connection level
> property for all tables referenced from the connection (as against UPSERTing
> each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004311#comment-17004311 ] Nitesh Maheshwari commented on PHOENIX-5634: [~sukuna...@gmail.com] Sure, I have updated the PR to additionally include these log lines. [~larsh] Indeed. About other smarter models - we should explore the possibilities, while ensuring that the overhead is minimal. > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 4.15.1 > > Time Spent: 2h > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001990#comment-17001990 ] Lars Hofhansl commented on PHOENIX-5634: Choosing the cache frequency - technically it's an interval, since we provide a time unit, not cycles per time unit, but anyway - per connection is powerful. One could set a permissive default and then control for connections that really need it exact (or vice versa). Also ... There are other models. Can we be smarter about this and know when a table is out of date without checking each time? Or can we start the query and then during the query detect an out of date table and then restart? Or something else? [~gjacoby] had some ideas. In any case this is a good start. > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 4.15.1 > > Time Spent: 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999599#comment-16999599 ] Maddineni Sukumar commented on PHOENIX-5634: Can we add a logline saying what is update_cache_frequency set in connection properties and also if possible a debug log line which says what the update_cache_frequency used while querying. > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 4.15.1 > > Time Spent: 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (PHOENIX-5634) Use 'phoenix.default.update.cache.frequency' from connection properties at query time
[ https://issues.apache.org/jira/browse/PHOENIX-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999567#comment-16999567 ] Nitesh Maheshwari commented on PHOENIX-5634: [~sukumaddineni] [~ckulkarni] [~jisaac] Can you review this please? > Use 'phoenix.default.update.cache.frequency' from connection properties at > query time > - > > Key: PHOENIX-5634 > URL: https://issues.apache.org/jira/browse/PHOENIX-5634 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Nitesh Maheshwari >Assignee: Nitesh Maheshwari >Priority: Minor > Fix For: 4.15.1 > > Time Spent: 10m > Remaining Estimate: 0h > > We have the config 'phoenix.default.update.cache.frequency' which specifies > the time a client should wait before it refreshes its metadata cache entry > for a table by fetching the latest metadata from system catalog. This value > could be set for a table in the following ways (in the following preference > order): > # Specifying UPDATE_CACHE_FREQUENCY in table creation DDL > # Specifying the connection property 'phoenix.default.update.cache.frequency' > # Using the default 'phoenix.default.update.cache.frequency' > At query time, we look at whether UPDATE_CACHE_FREQUENCY was specified for > the table and decide based on that value if the latest metadata for a table > should be fetched from system catalog to update the cache. However, when the > table doesn't have UPDATE_CACHE_FREQUENCY specified we should look at the > connection property 'phoenix.default.update.cache.frequency' (or the default > 'phoenix.default.update.cache.frequency' when the connection level property > is not set) to make that decision. The support for latter is missing - this > Jira is intended to add that. > This will aid exiting installations where the tables were created without a > specified UPDATE_CACHE_FREQUENCY, and thus always hit the system catalog to > get the latest metadata when referenced. With this support, we will be able > to reduce the load on system catalog by specifying a connection level > property for all tables referenced from the connection (as against UPSERTing > each table entry in system catalog to set an UPDATE_CACHE_FREQUENCY value). -- This message was sent by Atlassian Jira (v8.3.4#803005)
