After performing a server migration on CLM 6.0.3 the Link Index Provider (LDX) application page reports an error
After migrating data (using repotools-<context> -export / -import) and performing the lqe.restore operation on the ldx backup data - the ldx page on the new server reports the following problem. I have generated new ldx backup data from the original server - and it seems to get restored (because the /metadata and /datasets folders are removed and the lqe.restore flag in the /conf/ldx/lqe.properties file is changed from true to false) but my new server is unusable due to this error.
Have anyone else seen this and is there a fix?
Error Page ExceptionSRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.Original Exception:Error Message: javax.servlet.ServletException: java.io.IOException: org.apache.wink.json4j.JSONException: javax.crypto.BadPaddingException: Given final block not properly paddedError Code: 500 Target Servlet: GenericServletWrapper Error Stack: java.io.IOException: org.apache.wink.json4j.JSONException: javax.crypto.BadPaddingException: Given final block not properly padded at com.ibm.team.jis.lqe.auth.inbound.InboundAuthFilter.doFilter(InboundAuthFilter.java:97) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.auth.inbound.ConfigModeBlockerFilter.doFilter(ConfigModeBlockerFilter.java:77) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.auth.inbound.ConfigModeAllowedFilter.doFilter(ConfigModeAllowedFilter.java:56) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.auth.inbound.UpgradeModeBlockerFilter.doFilter(UpgradeModeBlockerFilter.java:89) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.auth.inbound.UpgradeModeAllowedFilter.doFilter(UpgradeModeAllowedFilter.java:53) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.http.ClickjackPreventionFilter.doFilter(ClickjackPreventionFilter.java:90) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.http.GZipFilter.doFilter(GZipFilter.java:47) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.team.jis.lqe.DefaultEncodingFilter.doFilter(DefaultEncodingFilter.java:34) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:1021) |
One answer
|
I came across the following note that may pertain to this problem:
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Additional Information:
The problem is most easily recreated by simply generating the LDX (or LQE) backup files then restoring from the backup files. Specifically (for LDX):
a. Initiate a backup from https://<your URI>/ldx/web/admin/backup (for example - backup to C:\LDX)
b. Copy the \datasets and \metadata folders found under C:\LDX\Backup2017***\ to the <install location>\server\conf\ldx folder.
c. Edit lqe.properties in the above folder location to set "lqe.restore=true"
d. Restart the LDX server
After the server has restarted and completed restoring from the backup files (indicated with the \datasets and \metadata folders are no longer visible under the \server\conf\ldx folder) then open https://<your URI>/ldx/web/admin/home. For me the error page described above was presented (ditto for the LQE admin home page if the LQE backup data was restored).
Also note: This problem was observed in 6.0.3 for a server using the SQL Server DBMS but was NOT observed for an Express install (using the Apache Derby DBMS).
The procedures to reproduce noted earlier were in error - it is not possible to observe this issue when when restoring from an LDX backup folders collected on the same machine.
Instead - the issue arises during a server migration activity from ServerMachine_A to ServerMachine_B. Prior to CLM 6.0.3 we were able to include the LDX/LQE backup data obtained from ServerMachine_A and restore them on ServerMachine_b after completing the steps to import the data migration files for the JTS/CCM/DCC/GC/RM/QM databases.
Now - however- it is necessary to either postpone the installation of the LDX/LQE applications until after the data for the other applications have been imported, OR to unregister LDX/LQE and then re-register them (followed by performing a complete index activity).
I have a work-around that will work for me - but am left with the question: Was this change (to eliminate the ability to include the LDX and LQE backup data as part of the data migration) deliberate, or accidental? If accidental I would ask that this be investigated because reindexing from scratch can take a very long time.