Member since
01-16-2018
602
Posts
46
Kudos Received
100
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
35 | 04-15-2024 12:28 AM | |
48 | 04-15-2024 12:17 AM | |
85 | 04-15-2024 12:04 AM | |
54 | 04-14-2024 11:54 PM | |
66 | 04-14-2024 11:45 PM |
12-23-2022
07:04 AM
Hello @Girija Internally, I wasn't able to replicate the issue being faced by you. I was able to create the ConfigSet using "_default" ConfigSet as baseConfig. I am assuming the issue is specific to your Environment & your team should use the CLI to better diagnose such issue. Your team can use the below solrctl command to create a ConfigSet with Solr KeyTab: solrctl config --create Test_Config _default -p configSetProp.immutable=false Assuming the above Command fails, Running the solrctl command with "--trace" after "solrctl" & before "config" would print the trace logging & assist in troubleshooting the issue faced by your team. Regards, Smarak
... View more
12-21-2022
07:04 AM
1 Kudo
Hello @SagarCapG Confirmed that Phoenix v5.1.0 has the Fix for "!primarykeys" to show the Primary Key linked with a Phoenix Table. Upon checking our Product Documentation, CDP v7.1.6 introduces Phoenix v5.1.0 [1]. As such, I am surprised your Team has Phoenix v5.0.0 with CDP v7.1.7, wherein Official v7.1.7 Doc [2] says Phoenix v5.1.1.7.1.7.0-551 is used. Since the Issue is fixed in Phoenix v5.1.x & CDP v7.1.6 onwards ship Phoenix v5.1.x, Kindly engage Cloudera Support to allow Support to review your Cluster for identifying the reasoning for CDP v7.1.7 using Phoenix v5.0.0. Or, Upgrade to Phoenix v5.1.x (If Customer is managing Phoenix outside of CDP) to use "!primarykeys" functionality. Regards, Smarak [1] What's New in Apache Phoenix | CDP Private Cloud (cloudera.com) [2] Cloudera Runtime component versions | CDP Private Cloud
... View more
12-20-2022
11:35 PM
Hello @brajeshreddy Since the Issue isn't replicated with CML release internally & your team have engaged Cloudera Support for further assistance, We shall Close the Post now. For our fellow Community Users, the Steps to perform the Team's Name Modification is shared above. Assuming the same isn't working for Customers, Ensure you are connected as MLAdmin & Caching is ruled out as well. Regards, Smarak
... View more
12-20-2022
08:28 AM
Hello @sekhar1 Since we haven't heard back from your side concerning the Post, We shall mark the Post as Resolved with the Action Plan to review if Traffic from your Machine isn't allowed to or from the Security Group linked with the VPC wherein the CML Workspace instances are deployed. Check if the Kubernetes Pods associated with the CML Workspace Kubernetes Cluster are Up/Running. If Yes, Such Exception should be reviewed from a Network Standpoint only. You may reach out to your Customer's AWS/Platform Team to review the Traffic between your Machine & the VPC within which the CML Workspace is deployed. Assuming your team fixed the issue outside of any Customer's Network concerns, We would appreciate your feedback to ensure our fellow Community Users can benefit from your experience. Regards, Smarak
... View more
12-20-2022
08:23 AM
Hello @brajeshreddy Thanks for using Cloudera Community. On a CML v2.0.34-b116, I was able to rename the Team's Name via UI as shared below via [1] & [2]. Upon Clicking On Team's Name, I get the UI [3], which allows me to modify the Team's Name. Since I am using the same Version as yours, the Issue likely lies with Permission (You may review the Access granted at Environment Level), Caching (You may clear the Browser Cache) etc. If both of the above checks aren't helpful, I suggest engaging Cloudera Support to ensure a Screen-Sharing Session can be done with your team to review further. Regards, Smarak [1] Name Before Change: [2] Name After Change: [3] Name Change Provisioning:
... View more
12-20-2022
07:54 AM
Hello @SagarCapG Thanks for using Cloudera Community. While I haven't tested the above Use-Case in Phoenix v5.0.0, I tested in Phoenix v5.1.0 (Used in CDP v7.1.7) & the same shows the Primary Key correctly [1]. As such, I believe the above ask is fixed in CDP v7.1.8 atleast. I reviewed Upstream JIRA & it appears the same is actually fixed in Phoenix v5.1.x as per comments in https://issues.apache.org/jira/browse/PHOENIX-6651. As such, Kindly plan for CDP v7.1.8 Upgrade for obtaining the concerned functionality of identifying PK via "!primarykeys". Regards, Smarak [1] 0: jdbc:phoenix:> CREATE TABLE Employee (EmpId Integer Not Null Primary Key, Ename Varchar(50));
0: jdbc:phoenix:> !primarykeys Employee;
+-----------+-------------+------------+-------------+---------+---------+-------------+-----------+-----------+-------------+---------+---------------+
| TABLE_CAT | TABLE_SCHEM | TABLE_NAME | COLUMN_NAME | KEY_SEQ | PK_NAME | ASC_OR_DESC | DATA_TYPE | TYPE_NAME | COLUMN_SIZE | TYPE_ID | VIEW_CONSTANT |
+-----------+-------------+------------+-------------+---------+---------+-------------+-----------+-----------+-------------+---------+---------------+
| | | EMPLOYEE | EMPID | 1 | | A | 4 | INTEGER | null | 4 | |
+-----------+-------------+------------+-------------+---------+---------+-------------+-----------+-----------+-------------+---------+---------------+
... View more
12-19-2022
12:34 AM
Hello @anks1 Thanks for using Cloudera Community. Kindly confirm the following details: CML Deployment (CDP Public Cloud Or Private Cloud) CML Version Used (Via CML Workspace Details In CML Page) Any timeframe of how many days before an App transition to Failed State from Running State Regards, Smarak
... View more
12-19-2022
12:32 AM
Hello @sekhar1 We wish to follow-up on the Post & confirm if your Team have resolved the issue. In Summary, such Exception are received if Traffic from your Machine isn't allowed to or from the Security Group linked with the VPC wherein the CML Workspace instances are deployed. Check if the Kubernetes Pods associated with the CML Workspace Kubernetes Cluster are Up/Running. If Yes, Such Exception should be reviewed from a Network Standpoint only. You may reach out to your Customer's AWS/Platform Team to review the Traffic between your Machine & the VPC within which the CML Workspace is deployed. Regards, Smarak
... View more
12-19-2022
12:15 AM
Hi @pacman A Merge happens for each Read Operation i.e. BlockCache & MemStore. As such, Incorrect Values aren't observed. Having said that, If you observe any such scenario of Read/Write Inconsistency, Kindly share a Use-Case & any replication attempt to allow us to review accordingly. Regards, Smarak
... View more
12-13-2022
07:39 AM
1 Kudo
Hello @pacman HFile is only updated after flush of Memstore. In the scenario shared, Read Merge would share the Updated values without updating the Hfile. We can perform the same by following for verification: 1. Create a Table with 1 CF. Insert 1 Row & flush Table to ensure 1 Hfile is created. 2. Read the Table, which would read from Hfile & place in BlockCache. The BlockCache Size is visible via HBase UI at the CF family level within the Table's Level Statistics, 3. Read the Table again, which would read from BlockCache. Verify via Hit Ratio from the BlockCache Stats in HBase UI. 4. Update the Row by using the same RowKey, yet using a different Value for the Column Qualifier within the Column Family. 5. Read the Table again. You should get the Updated Value from Step 4. 6. To make things interesting, Remove the concerned Table's 1 Region hosting RegionServer WAL file & Kill the RegionServer PID. This ensure the MemStore isn't flushed owing to Ungraceful exit & WAL can't be replayed. 7. Start the RegionServer, which shall create the WAL file. Read the Table again. The same would show Value from Step 1. This would help confirm the HFile isn't Updated when HBase Read Merge the Values from BlockCache & MemStore while reading the Table as per Step 5. Regards, Smarak
... View more