Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Connection URL different from Public URI: any side effects?

Questions
Tags
Users
Badges
Stefano Antoniazzi
(170●1●7●11) 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....

0 votes

3 answers
6,212 views
0 votes

3 answers

Permanent link
Stefano Antoniazzi
(170●1●7●11) 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.


0 votes

Permanent link
Stefano Antoniazzi
(170●1●7●11) 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)   

0 votes

Permanent link
Stefano Antoniazzi
(170●1●7●11) 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)


0 votes

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
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
× 6,121
× 76
× 5

Question asked: Sep 17 '12, 5:55 a.m.

Question was seen: 6,212 times

Last updated: Oct 04 '17, 5:15 a.m.

Confirmation Cancel Confirm