[jira] [Updated] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter
[ https://issues.apache.org/jira/browse/PHOENIX-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Kumar Maturi updated PHOENIX-4993: Attachment: PHOENIX-4993-master.addendum-1.patch > Data table region should not close RS level shared/cached connections like > IndexWriter, RecoveryIndexWriter > --- > > Key: PHOENIX-4993 > URL: https://issues.apache.org/jira/browse/PHOENIX-4993 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Kiran Kumar Maturi >Assignee: Kiran Kumar Maturi >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, > PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, > PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, > PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, > PHOENIX-4993-master.addendum-1.patch > > > Issue is related to Region Server being killed when one region is closing and > another region is trying to write index updates. > When the data table region closes it will close region server level > cached/shared connections and it could interrupt other region > index/index-state update. > -- Region1: Closing > {code:java} > TrackingParallellWriterIndexCommitter#stop() { > this.retryingFactory.shutdown(); > this.noRetriesFactory.shutdown(); > }{code} > closes the cached connections calling > CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java > > --Region2: Writing index updates > Index updates fail as connections are closed, which leads to > RejectedExecutionException/Connection being null. This triggers > PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the > the syscat table using the cached connections. Here it will not be able to > reach to SYSCAT , so we will trigger KillServreFailurePolicy. > CoprocessorHConnectionTableFactory#getTable() > > > {code:java} > if (connection == null || connection.isClosed()) { > throw new IllegalArgumentException("Connection is null or closed."); > }{code} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4450) When I use phoenix queary below my project appeared on such an error Can anyone help me?
[ https://issues.apache.org/jira/browse/PHOENIX-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Boado resolved PHOENIX-4450. -- Resolution: Not A Problem Assignee: Pedro Boado Not enough evidence of a problem provided. It looks like a development issue. > When I use phoenix queary below my project appeared on such an error Can > anyone help me? > > > Key: PHOENIX-4450 > URL: https://issues.apache.org/jira/browse/PHOENIX-4450 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: David New >Assignee: Pedro Boado >Priority: Critical > Labels: jdbc, phoenix, thin > > > {code:java} > Class.forName("org.apache.phoenix.queryserver.client.Driver"); >Connection conn= > DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.0.1:8765;serialization=PROTOBUF";); > String sqlerr=" SELECT > TO_CHAR(TO_DATE(SUCCESS_TIME,?),'-MM-dd') as success, " > + " COUNT(DISTINCT USER_ID) recharge_rs, " > + " COUNT(ID) recharge_rc, " > + " SUM(TO_NUMBER(ACTUAL_MONEY)) recharge_money " > + " FROM RECHARGE " > + " WHERE STATUS = 'success' AND RECHARGE_WAY != 'admin' > " > + " GROUP BY TO_CHAR(TO_DATE(SUCCESS_TIME,?),'-MM-dd') > "; > PreparedStatement pstmt = conn.prepareStatement(sqlerr); >pstmt.setString(1, "-MM-dd"); >pstmt.setString(2, "-MM-dd"); > ResultSet rs = pstmt.executeQuery(); > while (rs.next()) { > System.out.println((rs.getString("success").toString())); > } > {code} > > {code:java} > AvaticaClientRuntimeException: Remote driver error: RuntimeException: > java.sql.SQLException: ERROR 2004 (INT05): Parameter value unbound. Parameter > at index 1 is unbound -> SQLException: ERROR 2004 (INT05): Parameter value > unbound. Parameter at index 1 is unbound. Error -1 (0) null > java.lang.RuntimeException: java.sql.SQLException: ERROR 2004 (INT05): > Parameter value unbound. Parameter at index 1 is unbound > at org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:683) > at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:880) > at > org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:254) > at > org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1032) > at > org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:1002) > at > org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94) > at > org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46) > at > org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127) > at > org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) > at > org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at > org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499) > at > org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) > at > org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) > at > org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.sql.SQLException: ERROR 2004 (INT05): Parameter value > unbound. Parameter at index 1 is unbound > at > org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:483) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.jdbc.PhoenixParameterMetaData.getParam(PhoenixParameterMetaData.java:89) > at > org.apache.phoenix.jdbc.PhoenixParameterMetaData.isSigned(PhoenixParameterMetaData.java:138) > at > org.apache.calcite.avatica.jdbc.JdbcMeta.parameters(JdbcMeta.java:270) > at org.apache.calcite.avatica.jdbc.JdbcMeta.signature(JdbcMeta.java:282) > at org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:856) > ... 15 more > at > org.apache.calcite.avatica.remote.
[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client
[ https://issues.apache.org/jira/browse/PHOENIX-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Kumar Maturi updated PHOENIX-5094: Attachment: PHOENIX-5094-4.14-HBase-1.3.05.patch > Index can transition from INACTIVE to ACTIVE via Phoenix Client > --- > > Key: PHOENIX-5094 > URL: https://issues.apache.org/jira/browse/PHOENIX-5094 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.14.1 >Reporter: Monani Mihir >Assignee: Kiran Kumar Maturi >Priority: Major > Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch, > PHOENIX-5094-4.14-HBase-1.3.02.patch, PHOENIX-5094-4.14-HBase-1.3.03.patch, > PHOENIX-5094-4.14-HBase-1.3.04.patch, PHOENIX-5094-4.14-HBase-1.3.05.patch, > PHOENIX-5094-master.01.patch, PHOENIX-5094-master.02.patch, > PHOENIX-5094-master.03.patch > > > Suppose Index is in INACTIVE state and Client load is running continuously. > With INACTIVE State, client will keep maintaining index. > Before Rebuilder could run and bring index back in sync with data table, If > some mutation for Index fails from client side, then client will transition > Index state (From INACTIVE--> PENDING_DISABLE). > If client succeeds in writing mutation in subsequent retries, it will > transition Index state again ( From PENDING_DISABLE --> ACTIVE) . > Above scenario will leave some part of Index out of sync with data table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client
[ https://issues.apache.org/jira/browse/PHOENIX-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Kumar Maturi updated PHOENIX-5094: Attachment: PHOENIX-5094-master.03.patch > Index can transition from INACTIVE to ACTIVE via Phoenix Client > --- > > Key: PHOENIX-5094 > URL: https://issues.apache.org/jira/browse/PHOENIX-5094 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.14.1 >Reporter: Monani Mihir >Assignee: Kiran Kumar Maturi >Priority: Major > Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch, > PHOENIX-5094-4.14-HBase-1.3.02.patch, PHOENIX-5094-4.14-HBase-1.3.03.patch, > PHOENIX-5094-4.14-HBase-1.3.04.patch, PHOENIX-5094-4.14-HBase-1.3.05.patch, > PHOENIX-5094-master.01.patch, PHOENIX-5094-master.02.patch, > PHOENIX-5094-master.03.patch > > > Suppose Index is in INACTIVE state and Client load is running continuously. > With INACTIVE State, client will keep maintaining index. > Before Rebuilder could run and bring index back in sync with data table, If > some mutation for Index fails from client side, then client will transition > Index state (From INACTIVE--> PENDING_DISABLE). > If client succeeds in writing mutation in subsequent retries, it will > transition Index state again ( From PENDING_DISABLE --> ACTIVE) . > Above scenario will leave some part of Index out of sync with data table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter
[ https://issues.apache.org/jira/browse/PHOENIX-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon resolved PHOENIX-4993. --- Resolution: Fixed > Data table region should not close RS level shared/cached connections like > IndexWriter, RecoveryIndexWriter > --- > > Key: PHOENIX-4993 > URL: https://issues.apache.org/jira/browse/PHOENIX-4993 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Kiran Kumar Maturi >Assignee: Kiran Kumar Maturi >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, > PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, > PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, > PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, > PHOENIX-4993-master.addendum-1.patch > > > Issue is related to Region Server being killed when one region is closing and > another region is trying to write index updates. > When the data table region closes it will close region server level > cached/shared connections and it could interrupt other region > index/index-state update. > -- Region1: Closing > {code:java} > TrackingParallellWriterIndexCommitter#stop() { > this.retryingFactory.shutdown(); > this.noRetriesFactory.shutdown(); > }{code} > closes the cached connections calling > CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java > > --Region2: Writing index updates > Index updates fail as connections are closed, which leads to > RejectedExecutionException/Connection being null. This triggers > PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the > the syscat table using the cached connections. Here it will not be able to > reach to SYSCAT , so we will trigger KillServreFailurePolicy. > CoprocessorHConnectionTableFactory#getTable() > > > {code:java} > if (connection == null || connection.isClosed()) { > throw new IllegalArgumentException("Connection is null or closed."); > }{code} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter
[ https://issues.apache.org/jira/browse/PHOENIX-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon resolved PHOENIX-4993. --- Resolution: Resolved > Data table region should not close RS level shared/cached connections like > IndexWriter, RecoveryIndexWriter > --- > > Key: PHOENIX-4993 > URL: https://issues.apache.org/jira/browse/PHOENIX-4993 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Kiran Kumar Maturi >Assignee: Kiran Kumar Maturi >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, > PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, > PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, > PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, > PHOENIX-4993-master.addendum-1.patch > > > Issue is related to Region Server being killed when one region is closing and > another region is trying to write index updates. > When the data table region closes it will close region server level > cached/shared connections and it could interrupt other region > index/index-state update. > -- Region1: Closing > {code:java} > TrackingParallellWriterIndexCommitter#stop() { > this.retryingFactory.shutdown(); > this.noRetriesFactory.shutdown(); > }{code} > closes the cached connections calling > CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java > > --Region2: Writing index updates > Index updates fail as connections are closed, which leads to > RejectedExecutionException/Connection being null. This triggers > PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the > the syscat table using the cached connections. Here it will not be able to > reach to SYSCAT , so we will trigger KillServreFailurePolicy. > CoprocessorHConnectionTableFactory#getTable() > > > {code:java} > if (connection == null || connection.isClosed()) { > throw new IllegalArgumentException("Connection is null or closed."); > }{code} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter
[ https://issues.apache.org/jira/browse/PHOENIX-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon reopened PHOENIX-4993: --- > Data table region should not close RS level shared/cached connections like > IndexWriter, RecoveryIndexWriter > --- > > Key: PHOENIX-4993 > URL: https://issues.apache.org/jira/browse/PHOENIX-4993 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Kiran Kumar Maturi >Assignee: Kiran Kumar Maturi >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, > PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, > PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, > PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, > PHOENIX-4993-master.addendum-1.patch > > > Issue is related to Region Server being killed when one region is closing and > another region is trying to write index updates. > When the data table region closes it will close region server level > cached/shared connections and it could interrupt other region > index/index-state update. > -- Region1: Closing > {code:java} > TrackingParallellWriterIndexCommitter#stop() { > this.retryingFactory.shutdown(); > this.noRetriesFactory.shutdown(); > }{code} > closes the cached connections calling > CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java > > --Region2: Writing index updates > Index updates fail as connections are closed, which leads to > RejectedExecutionException/Connection being null. This triggers > PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the > the syscat table using the cached connections. Here it will not be able to > reach to SYSCAT , so we will trigger KillServreFailurePolicy. > CoprocessorHConnectionTableFactory#getTable() > > > {code:java} > if (connection == null || connection.isClosed()) { > throw new IllegalArgumentException("Connection is null or closed."); > }{code} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client
[ https://issues.apache.org/jira/browse/PHOENIX-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon resolved PHOENIX-5094. --- Resolution: Resolved Fix Version/s: 5.1.0 4.15.0 Pushed to master and 4.x branches. Thanks for the patch [~kiran.maturi] and [~mihir6692] > Index can transition from INACTIVE to ACTIVE via Phoenix Client > --- > > Key: PHOENIX-5094 > URL: https://issues.apache.org/jira/browse/PHOENIX-5094 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.14.1 >Reporter: Monani Mihir >Assignee: Kiran Kumar Maturi >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch, > PHOENIX-5094-4.14-HBase-1.3.02.patch, PHOENIX-5094-4.14-HBase-1.3.03.patch, > PHOENIX-5094-4.14-HBase-1.3.04.patch, PHOENIX-5094-4.14-HBase-1.3.05.patch, > PHOENIX-5094-master.01.patch, PHOENIX-5094-master.02.patch, > PHOENIX-5094-master.03.patch > > > Suppose Index is in INACTIVE state and Client load is running continuously. > With INACTIVE State, client will keep maintaining index. > Before Rebuilder could run and bring index back in sync with data table, If > some mutation for Index fails from client side, then client will transition > Index state (From INACTIVE--> PENDING_DISABLE). > If client succeeds in writing mutation in subsequent retries, it will > transition Index state again ( From PENDING_DISABLE --> ACTIVE) . > Above scenario will leave some part of Index out of sync with data table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5069) Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
[ https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Shi updated PHOENIX-5069: - Attachment: PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.002.patch > Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache > --- > > Key: PHOENIX-5069 > URL: https://issues.apache.org/jira/browse/PHOENIX-5069 > Project: Phoenix > Issue Type: Improvement >Reporter: Bin Shi >Assignee: Bin Shi >Priority: Major > Attachments: PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.001.patch, > PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.002.patch, > PHOENIX-5069.master.001.patch, PHOENIX-5069.master.002.patch, > PHOENIX-5069.master.003.patch, PHOENIX-5069.patch > > Time Spent: 6h 40m > Remaining Estimate: 0h > > The current Phoenix Stats Cache uses TTL based eviction policy. A cached > entry will expire after a given amount of time (900s by default) passed since > the entry's been created. This will lead to cache miss when > Compiler/Optimizer fetches stats from cache at the next time. As you can see > from the above graph, fetching stats from the cache is a blocking operation — > when there is cache miss, it has a round trip over the wire to scan the > SYSTEM.STATS Table and to get the latest stats info, rebuild the cache and > finally return the stats to the Compiler/Optimizer. Whenever there is a cache > miss, this blocking call causes significant performance penalty and see > periodic spikes. > *This Jira suggests to use asynchronous refresh mechanism to provide a > non-blocking cache. For details, please see the linked design document below.* > [~karanmehta93] [~twdsi...@gmail.com] [~dbwong] [~elserj] [~an...@apache.org] > [~sergey soldatov] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-5119) Work around RpcScheduler interface differences in HBase 1.5
Andrew Purtell created PHOENIX-5119: --- Summary: Work around RpcScheduler interface differences in HBase 1.5 Key: PHOENIX-5119 URL: https://issues.apache.org/jira/browse/PHOENIX-5119 Project: Phoenix Issue Type: Bug Reporter: Andrew Purtell Assignee: Andrew Purtell The RpcScheduler interface in HBase 1.5 has three new methods for exposing per handler type counts for RPC metrics. Implement them using reflection and avoid use of any @Override annotations so the code will continue to compile against earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5119) Work around RpcScheduler interface differences in HBase 1.5
[ https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated PHOENIX-5119: Attachment: PHOENIX-5119-4.x.patch > Work around RpcScheduler interface differences in HBase 1.5 > --- > > Key: PHOENIX-5119 > URL: https://issues.apache.org/jira/browse/PHOENIX-5119 > Project: Phoenix > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Attachments: PHOENIX-5119-4.x.patch > > > The RpcScheduler interface in HBase 1.5 has three new methods for exposing > per handler type counts for RPC metrics. Implement them using reflection and > avoid use of any @Override annotations so the code will continue to compile > against earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5119) Work around RpcScheduler interface differences in HBase 1.5
[ https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated PHOENIX-5119: Attachment: (was: PHOENIX-5119-4.x.patch) > Work around RpcScheduler interface differences in HBase 1.5 > --- > > Key: PHOENIX-5119 > URL: https://issues.apache.org/jira/browse/PHOENIX-5119 > Project: Phoenix > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > > The RpcScheduler interface in HBase 1.5 has three new methods for exposing > per handler type counts for RPC metrics. Implement them using reflection and > avoid use of any @Override annotations so the code will continue to compile > against earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5119) Work around RpcScheduler interface differences in HBase 1.5
[ https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated PHOENIX-5119: Attachment: PHOENIX-5119-4.x.patch > Work around RpcScheduler interface differences in HBase 1.5 > --- > > Key: PHOENIX-5119 > URL: https://issues.apache.org/jira/browse/PHOENIX-5119 > Project: Phoenix > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Attachments: PHOENIX-5119-4.x.patch > > > The RpcScheduler interface in HBase 1.5 has three new methods for exposing > per handler type counts for RPC metrics. Implement them using reflection and > avoid use of any @Override annotations so the code will continue to compile > against earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5080) Index becomes Active during Partial Index Rebuilder if Index Failure happens
[ https://issues.apache.org/jira/browse/PHOENIX-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated PHOENIX-5080: -- Attachment: PHOENIX-5080-4.x-HBase-1.3.06.patch > Index becomes Active during Partial Index Rebuilder if Index Failure happens > > > Key: PHOENIX-5080 > URL: https://issues.apache.org/jira/browse/PHOENIX-5080 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.1 >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Blocker > Attachments: PHOENIX-5080-4.x-HBase-1.3.01.patch, > PHOENIX-5080-4.x-HBase-1.3.02.patch, PHOENIX-5080-4.x-HBase-1.3.02.patch, > PHOENIX-5080-4.x-HBase-1.3.03.patch, PHOENIX-5080-4.x-HBase-1.3.04.patch, > PHOENIX-5080-4.x-HBase-1.3.05.patch, PHOENIX-5080-4.x-HBase-1.3.06.patch, > PHOENIX-5080-4.x-HBase-1.3.06.patch, PHOENIX-5080.01.patch, > PHOENIX-5080.01.patch > > > After PHOENIX-4130 and PHOENIX-4600 , If there is Index failure during > Partial Index Rebuild, Rebuilder will try again to write Index updates. If it > succeeds then it will transition Index from INACTIVE to ACTIVE, even before > Rebuilder finishes. > Here is where it goes wrong, I think :- > {code:java} > PhoenixIndexFailurePolicy.java :- > public static void doBatchWithRetries(MutateCommand mutateCommand, > IndexWriteException iwe, PhoenixConnection connection, > ReadOnlyProps config) throws IOException { > > while (canRetryMore(numRetry++, maxTries, canRetryUntil)) { > ... > handleIndexWriteSuccessFromClient(iwe, connection); > ... > } > } > > private static void handleIndexWriteSuccessFromClient(IndexWriteException > indexWriteException, PhoenixConnection conn) { > handleExceptionFromClient(indexWriteException, conn, > PIndexState.ACTIVE); > } > {code} > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)