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.
>>>>
>>>>
>>>>
>>>>
