How to resolve 'Given final block not properly padded' error encountered opening a data source in the node after a node joins the cluster ?

How to resolve 'Given final block not properly padded' error encountered opening a data source in the node after a node joins the cluster ?

book

Article ID: KB0072319

calendar_today

Updated On:

Products Versions
TIBCO Data Virtualization 8.0.x

Description

After a node joins the TIBCO Data Virtualization cluster, attempting to open any data source in the node results in an error of the type below:
-----------
"com.compositesw.common.security.CompositeSecurityException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
-----------

Resolution

Open TDV (TIBCO Data Virtualization) Studio, and check whether Administration >> Configuration >> Server >> Configuration >> Cluster >> Copy Repository Database For Cluster Join is set to " True".

User-added image

If it is set to "True", do the following:

1.    Disconnect the problem node from the cluster.

2.     IMPORTANT: If you do not have a current full server backup CAR taken from a good node (i.e. from a node that does not exhibit this issue), take a full server backup CAR from a good node. This is safety precaution, as the CAR will preserve all the metadata providing a rollback option in case needed.
        User-added image

3.    Change the value of ' Copy Repository Database For Cluster Join' from "True" to "False" on all nodes (including the disconnected node).

4.    Clear the repository on the disconnected node, as follows:

(a)   Shut down the TDV Server. 

(b)   Make sure that the Repository is still running. If you are unsure whether the Repository is running, you can find out as follows:

On Windows:
Open Windows Services and verify that the Repository has a " Running" status as shown below.
  User-added image

On Unix:
Run the command:    ps -elf | grep postgres
The command should list a postgres process with a "-D data" flag, as shown below.
User-added image

(c)   List all files under <TDV_INSTALL>\conf\repository\postgresql whose names begin with the  word 'composite_clean'. If the filenames contain version numbers (composite_clean- nnnnnnnnn.sql, where ' nnnnnnnnn' represents a version number), identify which filename contains the highest version number.

Example 
cd D:\TIBCO_DV\conf\repository\postgresql
dir composite_clean*
  •       composite_clean-080200001.sql
  •       composite_clean-080401001.sql
  •       composite_clean.sql
In the above example, composite_clean- 080401001.sql is the highest versioned file.

(d)   Clear the Repository by running repo_util.bat (or repo_util.sh) as follows.

NOTE: This will wipe out all the metadata, reverting the Repo to a "brand new install" state. Since the metadata is being deleted, a full server backup CAR should be maintained as a precaution (please see Step 2).

If there are no versioned files (i.e. only composite_clean.sql is present), run:
               repo_util.bat -dropSchema  
If there are versioned files, run:
               repo_util.bat  -dropSchema -schemaDropScript <highest versioned file>
            
Example
cd D:\TIBCO_DV\bin
repo_util.bat -dropSchema -schemaDropScript  D:\TIBCO_DV\conf\repository\postgresql\composite_clean- 080401001.sql

5.    Restart the TDV server.

If the server fails to start, check to see whether the TDV logs contain errors of the type  ' Failed executing SQL CREATE INDEX' accompanied by  'The repository could not be upgraded'. If these errors are present it means that  -schemaDropScript was required, but was omitted:

Example
-------------
INFO 2022-03-29  10:36:09.506 -0700 JdbcRepository - Failed repository operation: CREATE INDEX system_resource_properties_mid_index ON system_resource_properties(metadata_id);
ERROR 2022-03-29  10:36:09.508 -0700 RepositoryImpl - The repository could not be upgraded from version 31 to version 32.
Failed executing SQL CREATE INDEX system_resource_properties_mid_index ON system_resource_properties(metadata_id);. ERROR: relation "system_resource_properties_mid_index" already exists  [repository-2900112]
at com.compositesw.server.repository.internal.JdbcRepository.executeUpdate(JdbcRepository.java:11432) 
-------------

6.    Join the server back to the cluster.

NOTE: If Copy Repository Database For Cluster Join is already set to "False" (or if the above steps do not resolve the issue), please contact TIBCO Technical Support for assistance.

 

Issue/Introduction

After a node joins the cluster, opening a data source in the node results in a 'Given final block not properly padded' error. This article details how to resolve this error