HBASE-27820: HBase is not starting due to Jersey library conflicts wi… #5210
Conversation
…th javax.ws.rs.api jar
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
I think we should try to not ship this jar in the publish tarball, instead of excluding it when starting? |
I will push a change similar to the one in HBASE-26813 to see what all failures are seen with the change. Regarding removing the jar from the publish tarball, not sure if any other components depend on it. |
|
And we have shaded jersey in hbase-thirdparty and in hbase we should be using the shaded one, so could you please provide more information about the conflicts? What is the stack trace looks like? Thanks. |
|
Here is the stacktrace that is seen while starting the master node: 2022-11-17 10:32:26,423 ERROR org.apache.hadoop.hbase.master.HMaster: ***** ABORTING master atlas-zahf7j-master0.atlas-d7.l2ov-m7vs.int.cldr.work,16000,1668681139462: The coprocessor org.apache.atlas.hbase.hook.HBaseAtlasCoprocessor threw java.io.IOException: java.lang.InstantiationException: org.apache.atlas.hbase.hook.HBaseAtlasCoprocessor ***** |
Yes. I could see that hbase is using the shaded library, but it also adds the javax.ws.rs-api*.jar to the classpath while starting the server. Atlas co-processor on the other hand is using the non-shaded version of javax libraries which I think, is causing the conflict. Since HBase is not using the non-shaded version, I think, it's safe for HBase to not add it to the classpath. However, the library might be needed by some other components and hence, I am not sure if removing it from the bundle is safe or not. |
|
The jars are required when running UTs, where we want to start mini MR cluster, IIRC. For me I do not think we need to ship these jars, as we do not want to start a mini MR cluster even when starting a standalone mini hbase cluster. But better ask this on the dev list. If no objections, we could remove these jars from the bundle. Thanks. |
…th javax.ws.rs.api jar
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
Tests are failing with the following stacktrace: [ERROR] org.apache.hadoop.hbase.mapreduce.TestHBaseMRTestingUtility.testMRYarnConfigsPopulation Time elapsed: 0.214 s <<< ERROR! |
|
@Apache9 I think, a fix is needed in apache/hadoop/yarn to remove these jars or use shaded jars to avoid this issue. Until, that is done, our builds will keep on failing with the above mentioned error. Do you think, we can go back to my original change to avoid adding the javax.ws.rs-api jar to the hbase classpath while starting? |
|
This is a known issue. I mean we could try to exclude these jars in hbase-assembly? |
…th javax.ws.rs.api jar
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
The test failures seen above are because of timeouts. Is it possible to either suppress these errors or rerun the tests to see if they pass during rerun? [ERROR] org.apache.hadoop.hbase.io.hfile.TestBlockEvictionOnRegionMovement Time elapsed: 772.781 s <<< ERROR! [ERROR] org.apache.hadoop.hbase.replication.TestReplicationSmallTests.testGetReplicationPeerState[0: serialPeer=true] Time elapsed: 606.411 s <<< ERROR! |
|
retest |
|
@Apache9 , can you please take a look at the latest patch? The changes essentially avoid adding the javax.ws.rs-api jar to the bundle. There are couple of test failures reported during the test runs, but they are all timeout exceptions which I believe might be flaky and may go away on a rerun. Can we trigger a rerun to check that? |
|
@ragarkar , the changes look good to me I have re-triggered the Precommit job , let's see how the test responds, but it will be wise if you can execute the failed tests locally to confirm the same meanwhile |
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
@ankitsinghal, I have verified that the tests pass in the local builds. |
|
💔 -1 overall
This message was automatically generated. |
|
In this way we will not ship the java ws api jar in hbase-assembly? |
apache#5210) (apache#5261) Signed-off-by: Wellington Chevreuil <wchevreuil@apache.org> (cherry picked from commit 61a876f) Change-Id: I481fd8396d1ea0bf6fae884d9ef06f9cc8a6fa5f
…conflicts wi… (apache#5210) (apache#5261) Signed-off-by: Wellington Chevreuil <wchevreuil@apache.org> (cherry picked from commit 61a876f) Change-Id: I481fd8396d1ea0bf6fae884d9ef06f9cc8a6fa5f (cherry picked from commit ba7b4a2)
HBase is not starting due to Jersey library conflicts with javax.ws.rs.api jar
HBase uses shaded jersey jars and hence does not need to use this jar directly. However, it still adds this jar to the CLASSPATH while starting the server. Atlas on the other hand is using a non-shaded version of javax.ws.rs-api jar which causes this conflict and causes the hbase server fail while initializing atlas co-processor.
Since hbase is using shaded jersey jar and not using this jar directly, it should be removed from the bundle as it may cause similar conflicts with other client applications potentially using it.