It's all about the answers!

Ask a question

Connection URL different from Public URI: any side effects?


Stefano Antoniazzi (1701711) | asked Sep 17 '12, 5:55 a.m.
edited Oct 04 '17, 5:09 a.m.

 We absolutely know that we cannot change the public URI as stated in  https://jazz.net/library/article/749/


We would like to understand if the connection URL may be different from the public URI.
 
Specifically we have all the users and also the build engines that connect to the jazz server using the public URI (something like https://my.organization.intranet/jazz/ ).
We would like to get rid of all the overhead (there are some security tools that make connections slower) when we just have to load the build engine workspaces. May we just point to the ip of the RTC server? 
May we connect our build engines to RTC just pointing to the server with something like  https://10.xx.zz.yy:9443/jazz/  ? 
Our build also executes some code that connects and executes api code for versioning back some build output (we 're on 2.0.0.2 iFix6) and we found that we must connect in the same way the build engine connected for not getting errors. 

Just trying this it seemed to work (no manifest error)...but how we may be sure that the connecion url has not been used for some informations saved in the DB?
If I point for example to the change set created I just see the right "public URI" reference....

3 answers



permanent link
Stefano Antoniazzi (1701711) | answered Oct 02 '12, 5:19 a.m.
edited Oct 04 '17, 5:15 a.m.

 More info here:


In our site at the end we shut down IIS and made our Tomcat running RTC on port 443 (and not 9443).
Everything seems to work and we have no errors on the builds or on the server log.

So the final answer is:
1) don't change the connection URI, not even in the build engines 
2) you may change the destination of the connection uri using local host filet but you must stay on standard port (443)



permanent link
Stefano Antoniazzi (1701711) | answered Sep 27 '12, 7:18 a.m.
edited Sep 27 '12, 7:19 a.m.
 
First side effect of using IIS to redirect port 443 to 9443 ...: found on the server log for every build.....

Still I don't get what goes wrong and why.



 2012-09-24 14:25:30,851 [                 TP-Processor1] ERROR .ibm.team.jfs.app.discovery.utils.RootServicesUtil  - Error while fetching and parsing the root services document from "https://null:443/jazz/rootservices" with host "intranet.secservizi.sec:443"

java.net.UnknownHostException: null

      at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:236)

      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:389)

      at java.net.Socket.connect(Socket.java:551)

      at com.ibm.jsse2.jc.connect(jc.java:175)

      at com.ibm.team.http.client.impl.NaiveSSLSocketFactory.connectSocket(NaiveSSLSocketFactory.java:97)

      at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:129)

      at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)

      at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)

      at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:349)

      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)

      at com.ibm.team.http.client.impl.NullHttpCacheService.execute(NullHttpCacheService.java:33)

      at com.ibm.team.http.client.impl.HttpClientService.internalSend(HttpClientService.java:267)

      at com.ibm.team.http.client.impl.HttpClientService.send(HttpClientService.java:206)

      at com.ibm.team.jfs.app.discovery.utils.RootServicesUtil.initRootServicesDoc(RootServicesUtil.java:267)

      at com.ibm.team.jfs.app.discovery.utils.RootServicesUtil.getNodeList(RootServicesUtil.java:289)

      at com.ibm.team.jfs.app.discovery.utils.RootServicesUtil.getRdfResourceUrl(RootServicesUtil.java:296)

      at com.ibm.team.jfs.app.discovery.utils.RootServicesUtil.getStorageService(RootServicesUtil.java:149)

      at net.jazz.ajax.service.internal.RootServicesPropertyProvider.getRequiredProperty(RootServicesPropertyProvider.java:78)

      at net.jazz.ajax.internal.ajaxapplication.AjaxApplicationServlet$GlobalPropertyFragmentProvider.getResourceFragmentValue(AjaxApplicationServlet.java:485)

      at net.jazz.ajax.internal.resource.ResourceLoaderServlet.service(ResourceLoaderServlet.java:85)

      at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

      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:59)

      at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

      at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:121)

      at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:54)

      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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:679)

      at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:461)

      at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:399)

      at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)

      at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:316)

      at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:244)

      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)

      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)

      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)

      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)

      at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)

      at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)

      at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)

      at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)

      at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)

      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)

      at java.lang.Thread.run(Thread.java:811)   


permanent link
Stefano Antoniazzi (1701711) | answered Sep 24 '12, 4:58 a.m.
 It would be really appreciated to have an RTC Developer to answer.
In the meanwhile we just "fooled" the reverse proxy using the hosts file in the build engine machine and remapping port 443 to 9443 using IIS and the tomcat for IIS connector.

So the build engine uses the "public uri" connection but this is remapped to the ip of the RTC server and the 9443 port.


Your answer


Register or to post 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.