Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
In RSRpcServices, this (RSRpcServices) is passed to the create method: rpcSchedulerFactory.create(rs.conf, this)); RSRpcServices has reference to HRegionServer. If RSRpcServices implements Abortable and delegates to regionServer, RpcSchedulerFactory.create() would obtain the Abortable. Just my two cents. On Tue, Dec 30, 2014 at 4:36 PM, Alicia Shu a...@hortonworks.com wrote: If we would like to port this change to 0.98, another option is not changing RpcSchedulerFactory, but add a SET method for RpcScheduler that set the Abortable afterwards. Thus there will be no backward compatible issue. New code need to know to call the SET method. Old code will have a null abortable. Alicia On Tue, Dec 30, 2014 at 3:49 PM, James Taylor jamestay...@apache.org wrote: bq. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? Good question. Do you have an opinion? We have a compatibility check that we do on first connection to a cluster. Perhaps we can add a check of Phoenix server version vs HBase server version to detect a breakage scenario? In this case, we'd require the server-side Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it as well, but it's been my experience that folks just don't read this. So perhaps have the reflection in place in HBase long enough for us to get 4.4 out? Thanks for asking! James On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell andrew.purt...@gmail.com wrote: It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
bq. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? Good question. Do you have an opinion? We have a compatibility check that we do on first connection to a cluster. Perhaps we can add a check of Phoenix server version vs HBase server version to detect a breakage scenario? In this case, we'd require the server-side Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it as well, but it's been my experience that folks just don't read this. So perhaps have the reflection in place in HBase long enough for us to get 4.4 out? Thanks for asking! James On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell andrew.purt...@gmail.com wrote: It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Thanks for the feedback James. I filed HBASE-12787 in response. On Tue, Dec 30, 2014 at 3:49 PM, James Taylor jamestay...@apache.org wrote: bq. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? Good question. Do you have an opinion? We have a compatibility check that we do on first connection to a cluster. Perhaps we can add a check of Phoenix server version vs HBase server version to detect a breakage scenario? In this case, we'd require the server-side Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it as well, but it's been my experience that folks just don't read this. So perhaps have the reflection in place in HBase long enough for us to get 4.4 out? Thanks for asking! James On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell andrew.purt...@gmail.com wrote: It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
If we would like to port this change to 0.98, another option is not changing RpcSchedulerFactory, but add a SET method for RpcScheduler that set the Abortable afterwards. Thus there will be no backward compatible issue. New code need to know to call the SET method. Old code will have a null abortable. Alicia On Tue, Dec 30, 2014 at 3:49 PM, James Taylor jamestay...@apache.org wrote: bq. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? Good question. Do you have an opinion? We have a compatibility check that we do on first connection to a cluster. Perhaps we can add a check of Phoenix server version vs HBase server version to detect a breakage scenario? In this case, we'd require the server-side Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it as well, but it's been my experience that folks just don't read this. So perhaps have the reflection in place in HBase long enough for us to get 4.4 out? Thanks for asking! James On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell andrew.purt...@gmail.com wrote: It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Thanks, Andrew. I filed PHOENIX-1569 as well. On Tue, Dec 30, 2014 at 4:34 PM, Andrew Purtell apurt...@apache.org wrote: Thanks for the feedback James. I filed HBASE-12787 in response. On Tue, Dec 30, 2014 at 3:49 PM, James Taylor jamestay...@apache.org wrote: bq. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? Good question. Do you have an opinion? We have a compatibility check that we do on first connection to a cluster. Perhaps we can add a check of Phoenix server version vs HBase server version to detect a breakage scenario? In this case, we'd require the server-side Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it as well, but it's been my experience that folks just don't read this. So perhaps have the reflection in place in HBase long enough for us to get 4.4 out? Thanks for asking! James On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell andrew.purt...@gmail.com wrote: It would be a binary compatibility break unless we detect by reflection that it's an older factory missing the new 'create' method and therefore call the old one. We could add that. How many versions of HBase = 0.98.10 do you think would need to be binary compatible with 4.2.2? On Dec 30, 2014, at 3:23 PM, James Taylor jamestay...@apache.org wrote: Would our 4.2.2 binaries continue to work with releases of HBase containing this change? On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar enis@gmail.com wrote: Thanks Andrew, Once HBASE-12028 is committed it should be easy enough to make the changes in Phoenix to be able to compile with HBase versions pre or post HBASE-12028. But we need a PHOENIX issue for that. We should also make Abortable a LimitedPrivate it seems. Enis On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell andrew.purt...@gmail.com wrote: Hi Phoenix, Please see https://issues.apache.org/jira/browse/HBASE-12028 The proposed change if committed into 0.98 branch would introduce a new 'create' method into the RpcSchedulerFactory interface that receives an Abortable as an additional parameter. Thus, the factory can pass this on to schedulers and workers and if something terrible happens in or to a RPC handler they can trigger a server abort. Due to a design oversight we don't otherwise have this capability. In my opinion it is important to fix this oversight. (Phoenix can also potentially make use of the Abortable for fatal issues involving indexes.) Otherwise RPC handlers can silently terminate upon receiving an unhandled throwable, potentially leaving behind bad state, certainly impacting performance and availability. However because RpcSchedulerFactory is an interface any implementor will not compile after this change, until updated. HBase could include this change in the next 0.98 release or not. Please advise. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
