[
https://issues.apache.org/jira/browse/PHOENIX-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675451#comment-16675451
]
James Taylor edited comment on PHOENIX-4888 at 11/5/18 5:25 PM:
----------------------------------------------------------------
[~yonigo]: to get the tso to start for me, I had to increase the heap size by
making this change to omid.sh:
{code:java}
tso() {
exec java -Xmx4000m $JVM_FLAGS -cp $CLASSPATH org.apache.omid.tso.TSOServer
$@
}
{code}
I tried -Xmx2000m, but it still failed. Would you mind confirming what the
required heapsize is and attaching a new patch? Also, can you fall back to
HBASE_HOME if HBASE_CONF_DIR is not set? Often HBASE_HOME is the only
environment variable that people will have set.
One other question/request: is there a way to stop the tso too? If not, that'd
be something good to have.
FWIW, the sqlline.py script is the same as the psql.py script - if one works,
the other should too. After doing a {{mvn install -skipTests}}, I perform the
following steps:
* go to the phoenix/phoenix-assembly/target dir
* untar phoenix-4.14.0-HBase-1.3.tar.gz
* copy phoenix-4.14.0-HBase-1.3-server.jar into the hbase/lib directory
* restart your hbase server
* start the tso
* start bin/sqlline.py
* in sqlline.py, execute {{!autocommit off}} to turn autocommit off (otherwise
you won't be able to test conflict detection as every statement will be
committed after it's run). Would you mind adding this step to the directions
for transactions when you update the docs?
*Everything worked well for me, so I think we're good to go once the script is
fixed.*
One thing to be careful of when testing is if you're running different versions
of HBase on the same machine. If that's the case, then either reboot first (as
that'll remove the hbase tables in /tmp) or configure hbase to use different
directories for it's tables and zk state.
{quote}Why does phoenix rely on omid using WORLD_TIME, this seems like a bug in
phoenix?
{quote}
There's a correspondence in time stamps between table creation (CREATE TABLE
<table>) and table usage (SELECT ... FROM <table>). When a table is created in
Phoenix, it's not a transactional operation, so we need to convert from server
timestamp to transactional time stamp in that case so that when a SELECT is
done, we're able to resolve the table (when it's time stamp is multiplied by
10000000).
was (Author: jamestaylor):
[~yonigo]: to get the tso to start for me, I had to increase the heap size by
making this change to omid.sh:
{code:java}
tso() {
exec java -Xmx4000m $JVM_FLAGS -cp $CLASSPATH org.apache.omid.tso.TSOServer
$@
}
{code}
I tried -Xmx2000m, but it still failed. Would you mind confirming what the
required heapsize is and attaching a new patch? Also, can you fall back to
HBASE_HOME if HBASE_CONF_DIR is not set? Often HBASE_HOME is the only
environment variable that people will have set.
FWIW, the sqlline.py script is the same as the psql.py script - if one works,
the other should too. After doing a {{mvn install -skipTests}}, I perform the
following steps:
* go to the phoenix/phoenix-assembly/target dir
* untar phoenix-4.14.0-HBase-1.3.tar.gz
* copy phoenix-4.14.0-HBase-1.3-server.jar into the hbase/lib directory
* restart your hbase server
* start the tso
* start bin/sqlline.py
* in sqlline.py, execute {{!autocommit off}} to turn autocommit off (otherwise
you won't be able to test conflict detection as every statement will be
committed after it's run). I'll add this step to the directions for
transactions.
*Everything worked well for me, so I think we're good to go once the script is
fixed.*
One thing to be careful of when testing is if you're running different versions
of HBase on the same machine. If that's the case, then either reboot first (as
that'll remove the hbase tables in /tmp) or configure hbase to use different
directories for it's tables and zk state.
{quote}Why does phoenix rely on omid using WORLD_TIME, this seems like a bug in
phoenix?
{quote}
There's a correspondence in time stamps between table creation (CREATE TABLE
<table>) and table usage (SELECT ... FROM <table>). When a table is created in
Phoenix, it's not a transactional operation, so we need to convert from server
timestamp to transactional time stamp in that case so that when a SELECT is
done, we're able to resolve the table (when it's time stamp is multiplied by
10000000).
> Create script that starts Omid transaction manager
> --------------------------------------------------
>
> Key: PHOENIX-4888
> URL: https://issues.apache.org/jira/browse/PHOENIX-4888
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: Yonatan Gottesman
> Priority: Major
> Attachments: PHOENIX-4888.patch, PHOENIX-4888_v2.patch, omid4888.patch
>
>
> To support local testing of Omid support, we need to create a simple script
> (similar to bin/tephra) that starts the transaction manager.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
