Unsubscribe

[Vishal Khawarey]

Unsubscribe,
thanks.

Re: ON DUPLICATE KEY with Global Index

[Vincent Poon]

We do need to update the docs after PHOENIX-3925, which changed the
behavior from 'recommended' to 'mandatory'.
I'll update the docs now.

On Tue, Oct 9, 2018 at 1:08 PM Ankit Singhal 
wrote:

> We do not allow atomic upsert and throw the corresponding exception in the
> cases documented under the limitations section of
> http://phoenix.apache.org/atomic_upsert.html.  Probably a documentation
> needs a little touch to convey this clearly.
>
> On Tue, Oct 9, 2018 at 10:05 AM Josh Elser  wrote:
>
>> Can you elaborate on what is unclear about the documentation? This
>> exception and the related documentation read as being in support of each
>> other to me.
>>
>> On 10/9/18 5:39 AM, Batyrshin Alexander wrote:
>> >   Hello all,
>> > Documentations (http://phoenix.apache.org/atomic_upsert.html) say:
>> >
>> > "Although global indexes on columns being atomically updated are
>> supported, it’s not recommended as a potentially a separate RPC across the
>> wire would be made while the row is under lock to maintain the secondary
>> index."
>> >
>> > But in practice we get:
>> > CANNOT_USE_ON_DUP_KEY_WITH_GLOBAL_IDX(1224, "42Z24", "The ON DUPLICATE
>> KEY clause may not be used when a table has a global index." )
>> >
>> > Is this bug or documentation is outdated?
>> >
>>
>

Re: ON DUPLICATE KEY with Global Index

[Ankit Singhal]

We do not allow atomic upsert and throw the corresponding exception in the
cases documented under the limitations section of
http://phoenix.apache.org/atomic_upsert.html.  Probably a documentation
needs a little touch to convey this clearly.

On Tue, Oct 9, 2018 at 10:05 AM Josh Elser  wrote:

> Can you elaborate on what is unclear about the documentation? This
> exception and the related documentation read as being in support of each
> other to me.
>
> On 10/9/18 5:39 AM, Batyrshin Alexander wrote:
> >   Hello all,
> > Documentations (http://phoenix.apache.org/atomic_upsert.html) say:
> >
> > "Although global indexes on columns being atomically updated are
> supported, it’s not recommended as a potentially a separate RPC across the
> wire would be made while the row is under lock to maintain the secondary
> index."
> >
> > But in practice we get:
> > CANNOT_USE_ON_DUP_KEY_WITH_GLOBAL_IDX(1224, "42Z24", "The ON DUPLICATE
> KEY clause may not be used when a table has a global index." )
> >
> > Is this bug or documentation is outdated?
> >
>

Re: ON DUPLICATE KEY with Global Index

[Josh Elser]

Can you elaborate on what is unclear about the documentation? This 
exception and the related documentation read as being in support of each 
other to me.


On 10/9/18 5:39 AM, Batyrshin Alexander wrote:

  Hello all,
Documentations (http://phoenix.apache.org/atomic_upsert.html) say:

"Although global indexes on columns being atomically updated are supported, it’s not 
recommended as a potentially a separate RPC across the wire would be made while the row 
is under lock to maintain the secondary index."

But in practice we get:
CANNOT_USE_ON_DUP_KEY_WITH_GLOBAL_IDX(1224, "42Z24", "The ON DUPLICATE KEY clause 
may not be used when a table has a global index." )

Is this bug or documentation is outdated?

ON DUPLICATE KEY with Global Index

[Batyrshin Alexander]

 Hello all,
Documentations (http://phoenix.apache.org/atomic_upsert.html) say:

"Although global indexes on columns being atomically updated are supported, 
it’s not recommended as a potentially a separate RPC across the wire would be 
made while the row is under lock to maintain the secondary index."

But in practice we get:
CANNOT_USE_ON_DUP_KEY_WITH_GLOBAL_IDX(1224, "42Z24", "The ON DUPLICATE KEY 
clause may not be used when a table has a global index." )

Is this bug or documentation is outdated?

Re: Table dead lock: ERROR 1120 (XCL20): Writes to table blocked until index can be updated

[Batyrshin Alexander]

I've created bug with reproduce steps: 
https://issues.apache.org/jira/browse/PHOENIX-4960

> On 3 Oct 2018, at 21:06, Batyrshin Alexander <0x62...@gmail.com> wrote:
> 
> But we see that Phoenix commit() in our cases fails with "ERROR 1120 (XCL20): 
> Writes to table blocked until index can be updated" because of 
> org.apache.hadoop.hbase.NotServingRegionException.
> Expected that there must be retry and success for commit()
> 
>> On 2 Oct 2018, at 22:02, Josh Elser > > wrote:
>> 
>> HBase will invalidate the location of a Region on seeing certain exceptions 
>> (including NotServingRegionException). After it sees the exception you have 
>> copied below, it should re-fetch the location of the Region.
>> 
>> If HBase keeps trying to access a Region on a RS that isn't hosting it, 
>> either hbase:meta is wrong or the HBase client has a bug.
>> 
>> However, to the point here, if that region was split successfully, clients 
>> should not be reading from that region anymore -- they would read from the 
>> daughters of that split region.
>> 
>> On 10/2/18 2:34 PM, Batyrshin Alexander wrote:
>>> We tried branch 4.14-HBase-1.4 at commit 
>>> https://github.com/apache/phoenix/commit/52893c240e4f24e2bfac0834d35205f866c16ed8
>>>  
>>> 
>>> Is there any way to invalidate meta-cache on event of index regions split? 
>>> Maybe there is some option to set max time to live for cache?
>>> Watching this on regions servers:
>>> At 09:34 regions *96c3ede1c40c98959e60bd6fc0e07269* split on prod019
>>> Oct 02 09:34:39 prod019 hbase[152127]: 2018-10-02 09:34:39,719 INFO   
>>> [regionserver/prod019/10.0.0.19:60020-splits-1538462079117] 
>>> regionserver.SplitRequest: Region split, hbase:meta updated, and report to 
>>> master. Parent=IDX_MARK_O,\x0B\x46200020qC8kovh\x00\x01\x80\x00\x
>>> 01e\x89\x8B\x99@\x00\x00\x00\x00,1537400033958.*96c3ede1c40c98959e60bd6fc0e07269*.,
>>>  new regions: 
>>> IDX_MARK_O,\x0B\x46200020qC8kovh\x00\x01\x80\x00\x01e\x89\x8B\x99@\x00\x00\x00\x00,1538462079161.80fc2516619d8665789b0c5a2bca8a8b.,
>>>  IDX_MARK_O,\x0BON_SCHFDOPPR_2AL-5602
>>> 2B7D-2F90-4AA5-8125-4F4001B5BE0D-0_2AL-C0D76C01-EE7E-496B-BCD6-F6488956F75A-0_20180228_7E372181-F23D-4EBE-9CAD-5F5218C9798I\x46186195_5.UHQ=\x00\x02\x80\x00\x01a\xD3\xEA@\x80\x00\x00\x00\x00,1538462079161.24b6675d9e51067a21e58f294a9f816b..
>>>  Split took 0sec
>>> Fail at 11:51 prod018
>>> Oct 02 11:51:13 prod018 hbase[108476]: 2018-10-02 11:51:13,752 WARN   
>>> [hconnection-0x4131af19-shared--pool24-t26652] client.AsyncProcess: #164, 
>>> table=IDX_MARK_O, attempt=1/1 failed=1ops, last exception: 
>>> org.apache.hadoop.hbase.NotServingRegionException: 
>>> org.apache.hadoop.hbase.NotServingRegionException: Region 
>>> IDX_MARK_O,\x0B\x46200020qC8kovh\x00\x01\x80\x00\x01e\x89\x8B\x99@\x00\x00\x00\x00,1537400033958.*96c3ede1c40c98959e60bd6fc0e07269*.
>>>  is not online on prod019,60020,1538417663874
>>> Fail at 13:38 on prod005
>>> Oct 02 13:38:06 prod005 hbase[197079]: 2018-10-02 13:38:06,040 WARN   
>>> [hconnection-0x5e744e65-shared--pool8-t31214] client.AsyncProcess: #53, 
>>> table=IDX_MARK_O, attempt=1/1 failed=11ops, last exception: 
>>> org.apache.hadoop.hbase.NotServingRegionException: 
>>> org.apache.hadoop.hbase.NotServingRegionException: Region 
>>> IDX_MARK_O,\x0B\x46200020qC8kovh\x00\x01\x80\x00\x01e\x89\x8B\x99@\x00\x00\x00\x00,1537400033958.*96c3ede1c40c98959e60bd6fc0e07269*.
>>>  is not online on prod019,60020,1538417663874
 On 27 Sep 2018, at 01:04, Ankit Singhal >>>  >> wrote:
 
 You might be hitting PHOENIX-4785 
 >,  you can apply the 
 patch on top of 4.14 and see if it fixes your problem.
 
 Regards,
 Ankit Singhal
 
 On Wed, Sep 26, 2018 at 2:33 PM Batyrshin Alexander <0x62...@gmail.com 
  >> wrote:
 
Any advices? Helps?
I can reproduce problem and capture more logs if needed.
 
>On 21 Sep 2018, at 02:13, Batyrshin Alexander <0x62...@gmail.com 
> 
>>> wrote:
> 
>Looks like lock goes away 30 minutes after index region split.
>So i can assume that this issue comes from cache that configured
>by this option:*phoenix.coprocessor.maxMetaDataCacheTimeToLiveMs*
> 
> 
> 
>>On 21 Sep 2018, at 00:15, Batyrshin Alexander <0x62...@gmail.com 
>> 
>>>> wrote:
>> 
>>And how this split looks at Master lo