After performing a server migration on CLM 6.0.3 the Link Index Provider (LDX) application page reports an error

Daniel Barbour

(265●3●23) Jan 10 '17, 12:25 p.m.

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 Exception

SRVE0260E: 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 padded
Error 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)

0 votes

Comments

Daniel Barbour

Jan 11 '17, 11:33 a.m.

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).

Daniel Barbour

Feb 24 '17, 10:45 a.m.

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.

1 answer

6,431 views

0 votes

One answer

Permanent link

Daniel Barbour

(265●3●23) Feb 24 '17, 3:39 p.m.

I came across the following note that may pertain to this problem:

[from: https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.jp.lqe2.doc/topics/t_lqe_upgrade.html&scope=null]

"New in version 6.0.3: ..., the lqe.key file is created in the JTS_install_dir /server/conf/lqe directory. This file stores the key for encrypting LQE and Link Index Provider (LDX) passwords and credentials. ...If you delete this file, or if you move the JTS_install_dir /server/conf/lqe directory without moving lqe.key, you get an error when you start LQE. To learn how to resolve the issue, read this troubleshooting article."

0 votes

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

clm

× 7,621

migration

× 120

ldx

× 11

Question asked: Jan 10 '17, 12:25 p.m.

Question was seen: 6,431 times

Last updated: Feb 24 '17, 4:45 p.m.

After performing a server migration on CLM 6.0.3 the Link Index Provider (LDX) application page reports an error

Daniel Barbour

Error Page Exception

SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.

Original Exception:

Comments

Daniel Barbour

Daniel Barbour

1 answer

6,431 views

0 votes

One answer

Daniel Barbour

Your answer

Follow this question

Question details

Related questions