Description:
Two EMS servers are configured in load balancing mode and routing has been enabled between the EMS servers.

factories.conf  of both server 7222 and 7223 have been configured as follows:

[LBTopicConnectionFactory]
  type                      = topic
  url        = tcp://localhost:7222|tcp://localhost:7223
  metric        = connections

[LBQueueConnectionFactory]
  type                      = queue
  url                       = tcp://localhost:7222|tcp://localhost:7223
  metric        = connections

In BW, JNDI context URL is set as: tibjmsnaming://localhost:7222|tibjmsnaming://localhost:7223

A Test Connection from BW fails with the following error:

Supplied URL (tibjmsnaming://localhost:7222|tibjmsnaming://localhost:7223) contains an invalid port number: For input string: "7222|tibjmsnaming:"
Symptoms:
Test Connection fails with the following exception:

Supplied URL (tibjmsnaming://localhost:7222|tibjmsnaming://localhost:7223) contains an invalid port number: For input string: "7222|tibjmsnaming:"
Cause:
If using JNDI lookup in BW (or a standalone EMS application) you cannot use a pipe separated URL in the JNDI Context URL. The pipe separated URL is to be used only in the factories.conf of the EMS server so that the EMS server can route the actual connection to the appropriate EMS server. There is no point of using a pipe separated URL in the application’s JNDI context URL. The initial connection for JNDI lookup does not have anything to do with the pipe. The pipe will come into the picture only after you have finished the JNDI lookup and are ready to make an actual connection to an EMS server.

A Test Connection from Designer with the EMS server fails when the JNDI context URL uses a load balanced URL (pipe separated URL).

Suppose you have a pair of EMS servers on machine A (port AAAA) and B (port BBBB) configured in FT mode which you specifically use only as JNDI providers. You have another set of EMS servers running on machines C (port CCCC) and D (port DDDD), which are connected to each other via routes and they are the EMS servers which serve the actual messaging purpose. As A and B are configured as FT, they will be sharing all the secondary config files (i.e., queues.conf, topics.conf, factories.conf etc.). In the factories.conf shared by A and B, use the following configuration:

[LBTopicConnectionFactory]
  type                    = topic
  url                     = tcp://C:CCCC|tcp://D:DDDD
  metric        = connections

[LBQueueConnectionFactory]
  type                    = queue
  url                     = tcp://C:CCCC|tcp://D:DDDD
  metric        = connections

On the BW client side, select the checkbox “Use JNDI for connection factory” and set the JNDI context URL as:

tibjmsnaming://A:AAAA,tibjmsnaming://B:BBBB

In the advanced tab of the JMS connection, set the factory names as LBTopicConnectionFactory and LBQueueConnectionFactory. When BW starts it tries to do a JNDI lookup by connecting to server A (if server A is not running, it connects to server B). There is no point in load balancing the JNDI server connection as the connection made up for JNDI lookup is transient and short-lived. BW looks up the names LBTopicConnectionFactory and LBQueueConnectionFactory in the factories.conf (shared by server A and B), gets the URL of the actual message processing EMS server (C and D)and then closes the connection that it made to the JNDI servers (A or B). Then BW creates a new connection to the actual data processing EMS server (C or D) which has the least number of existing client connections. This is where the significance of the pipe comes in,  not when the client application is connecting to the JNDI server for the first time for JNDI lookups.

Instead of using a FT pair of EMS servers for JNDI provider, you can use a single EMS server for JNDI provider as well. In this case, the factories.conf of the JNDI EMS server should still be configured in the same way as earlier. Only in the JNDI Context URL of BW you would use something like:    tibjmsnaming://A:AAAA