[jira] [Updated] (PHOENIX-7165) getTable should retrieve PTable from server if not cached

2024-02-13 Thread Viraj Jasani (Jira)


 [ 
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

2024-02-13 Thread Kadir Ozdemir (Jira)


 [ 
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

2024-02-13 Thread Tanuj Khurana (Jira)


 [ 
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

2024-02-13 Thread Istvan Toth (Jira)


 [ 
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)