[jira] [Updated] (PHOENIX-7165) getTable should retrieve PTable from server if not cached
[ https://issues.apache.org/jira/browse/PHOENIX-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani updated PHOENIX-7165: -- Fix Version/s: 5.2.0 > getTable should retrieve PTable from server if not cached > - > > Key: PHOENIX-7165 > URL: https://issues.apache.org/jira/browse/PHOENIX-7165 > Project: Phoenix > Issue Type: Bug >Reporter: Kadir Ozdemir >Assignee: Kadir Ozdemir >Priority: Major > Fix For: 5.2.0 > > > PhoenixConnection#getTable gets a PTable from the PTable cache per JVM. If > the table is not in the cache then, it trows TableNotFoundException. > PhoenixRuntime#getTable calls first PhoenixConnection#getTable and if the > table is not in the cache, it retrieves table from the server. > Since a user table can be evicted from the cache any time, all getTable > methods should retrieve PTable objects from the server if they are not cached > on the client side. > Phoenix internal operations should use PhoenixConnection getTable operations > instead of PhoenixRuntime ones. PhoenixRuntime getTable operations should > simply call the corresponding PhoenixConnection getTable operations in order > to unify the implementation of all getTable operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (PHOENIX-7165) getTable should retrieve PTable from server if not cached
[ https://issues.apache.org/jira/browse/PHOENIX-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir Ozdemir resolved PHOENIX-7165. Resolution: Fixed > getTable should retrieve PTable from server if not cached > - > > Key: PHOENIX-7165 > URL: https://issues.apache.org/jira/browse/PHOENIX-7165 > Project: Phoenix > Issue Type: Bug >Reporter: Kadir Ozdemir >Assignee: Kadir Ozdemir >Priority: Major > > PhoenixConnection#getTable gets a PTable from the PTable cache per JVM. If > the table is not in the cache then, it trows TableNotFoundException. > PhoenixRuntime#getTable calls first PhoenixConnection#getTable and if the > table is not in the cache, it retrieves table from the server. > Since a user table can be evicted from the cache any time, all getTable > methods should retrieve PTable objects from the server if they are not cached > on the client side. > Phoenix internal operations should use PhoenixConnection getTable operations > instead of PhoenixRuntime ones. PhoenixRuntime getTable operations should > simply call the corresponding PhoenixConnection getTable operations in order > to unify the implementation of all getTable operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-7213) Add option for unlimited phoenix.query.QueueSize
[ https://issues.apache.org/jira/browse/PHOENIX-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanuj Khurana updated PHOENIX-7213: --- Description: As discussed in PHOENIX-7117 _*phoenix.query.queueSize*_ limits can cause scan queries on table with lot of regions to fail. I did some profiling and found that each task allocates 48 bytes. So I am adding an enhancement to make the queue size unlimited if we set the limit to -1. We still have a limit on the number of tasks that can be executed in parallel controlled by the _*phoenix.query.threadPoolSize*_ If you don't enforce the limit, the only thing that is limiting is the jvm heap allocated. was: As discussed in [PHOENIX-7117|https://issues.apache.org/jira/browse/PHOENIX-7117] _*phoenix.query.queueSize*_ limits can cause scan queries on table with lot of regions to fail. I did some profiling and found that each task allocates 48 bytes. So I am adding an enhancement to not enforce this limit (or an infinite queue ) if we set the limit to -1. We still have a limit on the number of tasks that can be executed in parallel controlled by the _*phoenix.query.threadPoolSize*_ If you don't enforce the limit, the only thing that is limiting is the jvm heap allocated. Summary: Add option for unlimited phoenix.query.QueueSize (was: Don't enforce phoenix.query.queueSize limits) > Add option for unlimited phoenix.query.QueueSize > > > Key: PHOENIX-7213 > URL: https://issues.apache.org/jira/browse/PHOENIX-7213 > Project: Phoenix > Issue Type: Improvement >Reporter: Tanuj Khurana >Assignee: Tanuj Khurana >Priority: Major > > As discussed in PHOENIX-7117 _*phoenix.query.queueSize*_ limits can cause > scan queries on table with lot of regions to fail. I did some profiling and > found that each task allocates 48 bytes. So I am adding an enhancement to > make the queue size unlimited if we set the limit to -1. We still have a > limit on the number of tasks that can be executed in parallel controlled by > the > _*phoenix.query.threadPoolSize*_ > > If you don't enforce the limit, the only thing that is limiting is the jvm > heap allocated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (PHOENIX-7188) Remove Omid TTable.getTableDescriptor() calls
[ https://issues.apache.org/jira/browse/PHOENIX-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved PHOENIX-7188. -- Resolution: Fixed > Remove Omid TTable.getTableDescriptor() calls > - > > Key: PHOENIX-7188 > URL: https://issues.apache.org/jira/browse/PHOENIX-7188 > Project: Phoenix > Issue Type: Improvement > Components: core >Affects Versions: 5.2.0, 5.1.4 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Critical > Fix For: 5.2.0, 5.1.4 > > > Once we have upgraded to Omid 1.1.1, replace TTable#getTableDescriptor() > calls with > TTable#getHBaseTable()#getTableDescriptor(). > This is to allow for potentially building with future Omid versions, which > will remove TTable#getTableDescriptor(). -- This message was sent by Atlassian Jira (v8.20.10#820010)