[jira] [Commented] (PHOENIX-6615) The Tephra transaction processor cannot be loaded anymore.
[ https://issues.apache.org/jira/browse/PHOENIX-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463052#comment-17463052 ] Istvan Toth commented on PHOENIX-6615: -- On transaction support generally: Yes, I do get the feeling that very few people are using it, and if they do, they are not telling. Even before I broke it in PHOENIX-6064 Tephra support has been broken more than not, as Tephra needs a new release for every HBase minor version, otherwise it will fail to start. The last release supports up to HBase 2.4 and 1.6 IIRC. (The IT suite doesn't catch the missing HBase support, either) The glass is actually half-full, as we do support Omid + Phoenix at dayjob, and if you check the commit log, Rajeshbabu and I ironed out quite a few kinks out of that in the past year (like Kerberos not working at all), so we know that Omid and Phoenix + Omid is in a workable state (at least on our branch, which is basically Omid HEAD, minus the incompatible maven changes). We are also regularly running some (basic) E2E tests for it. (Omid needs a new release to get the rest of those fixes and improvements officially out, BTW) We did have two Omid contributors, who are not on the #dayjob team in the last year, with some much needed Omid build system improvements, but not even any bug reports on Tephra. We have worked on Tephra, mostly to keep Tephra working with newer HBase minore releases, and to somewhat isolate us from the CVEs in it, but more out of wanting the keep Phoenix CVE free (check) and intact (fail), than because we had any plans for Tephra beyond that. In other words, the work we do on Tephra relates more to keeping the rest of Phoenix building and safe than keeping Tephra working (much less improving it). All that I know about Tephra and Tephra support in Phoenix points to it being abandoned at this point. As any unmaintained code, Tephra is a liability, (hence PHOENIX-6064), and making Tephra secure is a non-trivial amount of work. (need to rip out and replace Twill, and update Guava at least, and fix any JVM incompatibilities that you've mentioned) I estimate that it'd take about 1-3 weeks depending on familiarity with Twill, Guava and ZK. I'm of course going to test and apply your fix to PHOENIX-6064 (thanks again), and I may make Tephra point releases for new HBase minor versions (1.7 support is known to be missing), but if no maintainer steps up for Tephra (who actually cares about it, and can commit time to it), then we need to revisit the previous discussion on the long-term viability of Tephra. I'm beginning to doubt that the half-hearted job I do at maintaining Tephra (i.e. adding support for new HBase releases) is beneficial, as it may give the illusion of a properly maintained project to an outside observer. Should we take the Tephra discussion to the dev/user list next year ? > The Tephra transaction processor cannot be loaded anymore. > -- > > Key: PHOENIX-6615 > URL: https://issues.apache.org/jira/browse/PHOENIX-6615 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.2 >Reporter: Lars Hofhansl >Priority: Major > Attachments: 6615.txt > > > See > # TransactionFactory > # TephraTransactionProvider > Can you spot the problem? :) (Hint: The constructor is private.) > Broken since PHOENIX-6064. [~stoty] . > Can I just say... Unless I am missing something... How could we not have > noticed that one of the transaction processors has not been working since > August (in 5.x at least)? Is really nobody using the transaction engines? > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PHOENIX-6571) Hang of connections after OutOfMemoryError
[
https://issues.apache.org/jira/browse/PHOENIX-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463043#comment-17463043
]
Aleksey Stavrov commented on PHOENIX-6571:
--
Sorry I didn't reply for a long time.
I was hoping I could take the time and try looking at something in the
profiler. At the moment, I have lost the whole context, since I no longer work
in the company where this problem arose in production and I cannot help with
anything, and I understand that without additional help will not solve anything
here. I suggest just closing this topic.
> Hang of connections after OutOfMemoryError
> ---
>
> Key: PHOENIX-6571
> URL: https://issues.apache.org/jira/browse/PHOENIX-6571
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 4.16.1
>Reporter: Aleksey Stavrov
>Priority: Major
>
> We often have connection hangs after OOM. Hangs often occur on locks.
> I made a test case locally that reproduces this problem, but I don't know
> Java, so I have a complex bundle (perl -> dbd_jdbc -> hbase/phoenix) to use
> phoenix, so because of this i am not showing a minimal example to reproduce
> this behavior.
> Here is the error log shown by dbd_jdbc: [https://pastebin.com/sHcH2iVq]
> After the OOM happened, all connections to dbd_jdbc hang and very often have
> such a stack trace:
> {noformat}
> "Thread-18" #197 prio=5 os_prio=0 cpu=21.70ms elapsed=1822.79s
> tid=0x7ffaa4124800 nid=0x1c84 waiting on condition [0x7ff9c0ecc000]
>
>
>java.lang.Thread.State: WAITING (parking)
>
>
>
> at jdk.internal.misc.Unsafe.park(java.base@11.0.12/Native Method)
>
>
>
> - parking to wait for <0xf82e9998> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>
>
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.12/LockSupport.java:194)
>
>
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.12/AbstractQueuedSynchronizer.java:885)
>
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.12/AbstractQueuedSynchronizer.java:917)
>
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.12/AbstractQueuedSynchronizer.java:1240)
>
>
> at
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.12/ReentrantLock.java:267)
>
>
>
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1326)
>
>
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1230)
>
>
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1214)
>
>
> at
>
[jira] [Commented] (PHOENIX-6615) The Tephra transaction processor cannot be loaded anymore.
[ https://issues.apache.org/jira/browse/PHOENIX-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463030#comment-17463030 ] Istvan Toth commented on PHOENIX-6615: -- Thank you [~larsh], yes, that was the idea. Sorry about the breakage, I will look at this after the holidays. > The Tephra transaction processor cannot be loaded anymore. > -- > > Key: PHOENIX-6615 > URL: https://issues.apache.org/jira/browse/PHOENIX-6615 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.2 >Reporter: Lars Hofhansl >Priority: Major > Attachments: 6615.txt > > > See > # TransactionFactory > # TephraTransactionProvider > Can you spot the problem? :) (Hint: The constructor is private.) > Broken since PHOENIX-6064. [~stoty] . > Can I just say... Unless I am missing something... How could we not have > noticed that one of the transaction processors has not been working since > August (in 5.x at least)? Is really nobody using the transaction engines? > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PHOENIX-6615) The Tephra transaction processor cannot be loaded anymore.
[ https://issues.apache.org/jira/browse/PHOENIX-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463016#comment-17463016 ] Lars Hofhansl commented on PHOENIX-6615: I guess something like this is what you wanted... Attempt to load the singleton via reflection. > The Tephra transaction processor cannot be loaded anymore. > -- > > Key: PHOENIX-6615 > URL: https://issues.apache.org/jira/browse/PHOENIX-6615 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.2 >Reporter: Lars Hofhansl >Priority: Major > Attachments: 6615.txt > > > See > # TransactionFactory > # TephraTransactionProvider > Can you spot the problem? :) (Hint: The constructor is private.) > Broken since PHOENIX-6064. [~stoty] . > Can I just say... Unless I am missing something... How could we not have > noticed that one of the transaction processors does not work since August? Is > really nobody using the transaction engines? > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (PHOENIX-6064) Make Tephra support optional
[ https://issues.apache.org/jira/browse/PHOENIX-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463007#comment-17463007 ] Lars Hofhansl commented on PHOENIX-6064: Turns out this actually break Tephra completely and nobody even noticed. Not blaming this change, but Phoenix and associated projects have started to bitrot it seems. Anyway... I don't work on this more, was just trying something unrelated. Which then turned in a few hours getting Tephra to build without no longer supported JDKs following by the realization that Phoenix cannot even load the TephraTransactionProvider anymore. Not sure why I even care - and if this sounds frustrated is because I am. > Make Tephra support optional > > > Key: PHOENIX-6064 > URL: https://issues.apache.org/jira/browse/PHOENIX-6064 > Project: Phoenix > Issue Type: Improvement > Components: core, tephra >Affects Versions: 5.1.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: 5.1.0 > > Attachments: PHOENIX-6064.master.v1.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Tephra has and old Guava dependency, that cannot be removed due to Twill > depending on it. Removing the Twill dependency from Tephra is possible, but > not trivial. > This Guava has CVEs, which will show up in static analysis tools, which will > cause some potential users not to adopt Phoenix. > Provide an option to build Phoenix without Tephra, and its problematic > dependencies. -- This message was sent by Atlassian Jira (v8.20.1#820001)
