CRJAZ1938E error when registering CCM and QM applications
We're currently trying to implement a distributed CLM installation as documented in the CLM help here: http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=/com.ibm.jazz.install.doc/topics/c_reverse_proxy.html
We have 5 servers:
with proxy-server being a reverse proxy for the back-end application servers.
We're using Tomcat as the application server and Apache HTTP server as the reverse proxy.
The issue we have is that when we try to register the CCM and QM applications we get the error:
This issue seems to be caused by the proxy server because if we change the discovery URL from https://proxy-server/ccm/scr to https://ccm-server/ccm/scr the registration works successfully.
It seems that the proxy can communicate with the CCM server because after entering the discovery URL of https://proxy-server/ccm/scr the "Application Type" and "Functional User" fields are automatically populated with the correct values.
The relevant configuration from our proxy server is:
I've already raised a PMR over this but was hoping that maybe someone else has seen this before.
Thanks
We have 5 servers:
- jts-server
rrc-server
ccm-server
rqm-server
proxy-server
with proxy-server being a reverse proxy for the back-end application servers.
We're using Tomcat as the application server and Apache HTTP server as the reverse proxy.
The issue we have is that when we try to register the CCM and QM applications we get the error:
011-07-04 10:58:55,938 [ http-9443-Processor25] ERROR .service.internal.setup.RegistrationHandlerService - Error handling registration request null
com.ibm.team.repository.common.TeamRepositoryException: CRJAZ1938E Unable to validate that consumer key and secret are valid for the JTS at "https://proxy-server/jts"
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.initializeRegistration(RegistrationHandlerService.java:243)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.perform_POST(RegistrationHandlerService.java:174)
at com.ibm.team.repository.service.TeamRawService.service(TeamRawService.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:370)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:356)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
at $Proxy82.service(Unknown Source)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.doRestService(AbstractTeamServerServlet.java:823)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(AbstractTeamServerServlet.java:1864)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(AbstractTeamServerServlet.java:1723)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1632)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:111)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:811)
Caused by:
com.ibm.team.jfs.app.http.HttpInternalServerErrorException: Request to service https://proxy-server/jts/service/com.ibm.team.repository.service.internal.discovery.IFriendsAdminRestService/friends?includeInternal=true failed with status code 404 and response body
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.checkHttpResponse(RegistrationHandlerService.java:724)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.access$1(RegistrationHandlerService.java:706)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService$4.handleResponse(RegistrationHandlerService.java:697)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService$4.handleResponse(RegistrationHandlerService.java:1)
at com.ibm.team.jfs.app.http.client.JazzHttpClient.execute(JazzHttpClient.java:257)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:709)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:700)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.executeJtsRequest(RegistrationHandlerService.java:702)
at com.ibm.team.repository.service.internal.setup.RegistrationHandlerService.initializeRegistration(RegistrationHandlerService.java:234)
... 39 more
This issue seems to be caused by the proxy server because if we change the discovery URL from https://proxy-server/ccm/scr to https://ccm-server/ccm/scr the registration works successfully.
It seems that the proxy can communicate with the CCM server because after entering the discovery URL of https://proxy-server/ccm/scr the "Application Type" and "Functional User" fields are automatically populated with the correct values.
The relevant configuration from our proxy server is:
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /jts https://jts-server:9443/jts
ProxyPassReverse /jts https://jts-server:9443/jts
ProxyPass /ccm https://ccm-server:9443/ccm
ProxyPassReverse /ccm https://ccm-server:9443/ccm
...
similar config for other applications
I've already raised a PMR over this but was hoping that maybe someone else has seen this before.
Thanks
3 answers
Hi,
The proxy is up and running when doing the setup - it redirects you to it after entering the public URL field.
This is quite a strange issue as the applications do work with a reverse proxy, but only when all the applications are installed on the same server. The setup also works fine in a distributed topology when you point the discovery URL at the physical application servers. It's only when you have a combination of a distributed topology and a reverse proxy that you see this problem.
The PMR is still being investigated so I'll post an update when I get a solution.
The proxy is up and running when doing the setup - it redirects you to it after entering the public URL field.
This is quite a strange issue as the applications do work with a reverse proxy, but only when all the applications are installed on the same server. The setup also works fine in a distributed topology when you point the discovery URL at the physical application servers. It's only when you have a combination of a distributed topology and a reverse proxy that you see this problem.
The PMR is still being investigated so I'll post an update when I get a solution.
Hi Jared,
this is just a wild guess.....
As far as I know the proxy needs to be up and you need to do the setup while running the proxy. As far as I know you would also use the proxy URI's during setup. Maybe you get different URI's on JTS and application and that is why the register fails?