I have a java application which does some JMS send&receive work. But I found an interesting problem. For example, I set the following for java.naming.provider.url.
tcp://hostnameA.foo.bar:7222
But I got the error as below. Only hostname in it, not the full qualified domain name.
javax.jms.JMSException: Failed to connect to the server at tcp://hostnameA:7222
Unless I add hostnameA in my hosts file manually, it won't connect to Tibco server.
How can I fix it?
Thanks in advance.
The EMS Server has its own built-in JNDI server. What you're actually doing when you connect is 1) querying the EMS:s JNDI server for a connection factory definition and then 2) creating a connection based on the returned factory. This is implied by the fact that you're using java.naming.provider.url.
Change the connection factory definition (factories.conf) on the EMS server for the connection factory you're using. The default definition for the default factories (e.g. QueueConnectionFactory) on a fresh install is "tcp://7222" which will be replaced by "tcp://hostname:7222" by the server when retrieved. You can change this definition to e.g. "tcp://hostname.myfqdn.com:7222" and things should work.
You could also bypass the JNDI server completely by creating a connection directly, but I wouldn't recommend this since the connection factory definition returned by the server may contain information about load balanced and fault tolerant pairs, SSL settings, or point to a completely different server pair etc. It also allows the EMS administrators to change the definition of connection factories without the clients having to change their code or even their configuration.
I guess this has nothing to do with the programming layer.
Your DNS query for that name is unresolvable, that's why it works when you edit your hosts-file.
Either check your system's DNS settings (or make sure the dns server which is in your system's configuration replies to your name query), or use the IP-address instead.
Related
We have a solace broker running in a docker container. When we create a JNDI Connection Factory there are default properties such as
Reconnect Retry Attempts
Connect Retry Attempts
Connect Retry Attempts per Host
and so on
When we establish a producer using JMS we give properties like so
env.put(SupportedProperty.SOLACE_JMS_JNDI_CLIENT_ID, config.getJndiClientID());
env.put(SupportedProperty.SOLACE_JMS_PROP_SENDER_ID, config.getSenderID());
env.put(SupportedProperty.SOLACE_JMS_VPN, config.getVpn());
env.put(SupportedProperty.SOLACE_JMS_JNDI_CONNECT_RETRIES, 0);
env.put(SupportedProperty.SOLACE_JMS_JNDI_RECONNECT_RETRIES, 0);
env.put(SupportedProperty.SOLACE_JMS_JNDI_CONNECT_RETRIES_PER_HOST, 0);
however at the run-time of application and at the point when connection is getting established it seems that these properties that I set on the client side take no effect. Specifically I was able to test that by stopping the docker container of solace and seeing that it is trying to reconnect 3 times which is what happens to be the default is on the broker side.
Therefore, the question, how to force the override of these properties on the client side, if at all possible? Under what circumstances does setting these properties on a client side take affect?
Loading of a JMS ConnectionFactory over JNDI is, per definition, a two step process: first the API connects to JNDI and then loads whatever JMS ConnectionFactory object has been created.
Property SOLACE_JMS_JNDI_CONNECT_RETRIES (note the JNDI) is actually the parameter for the first step ! It defines the #retries for contacting JNDI. If you want to change the definition of the loaded JMS ConnectionFactory, you need to do this in your Solace administrator. For example within admin GUI as shown below.
When you use env.put(), you are trying to set the JMS Property using the Initial Context.
But these properties could also be set through the JNDI properties file as well as the command line.
If you turn on the API debugging, you should be able to see which value is taken from where.
Now, once you are able to connect with the JNDI connection factory on the broker, the values will be taken from the broker side.
I'm looking for a secure way to tunnel RMI traffic.
In My application(java Webstart) i must assume that the only port that is open is port 80.
I have the looked att socketfactories for rmi but do i really need a proxy then.
I need to do all my tunneling on the client side.
The only firewall i am trying to get past is on the client side.
I'm not able to open 1099 with port ranges above.
Would be nice to see some implementations.
Thanks!
Port 1099 was reserved for RMI at IANA in about 1995. There is no reason for it not to be open for outbound access in the client-side firewall.
RMI can be made to use fixed port numbers by supplying a port number when constructing (super(port)) or exporting (exportObject(object, port)). Better still, if you create the Registry within the server JVM via LocateRegistry.createRegistry(), all subequently exported remote objects will use that port unless they specify a different port or they use a server socket factory.
BUT ... RMI already includes HTTP tunneling 'out of the box'. No external solution required. You have to deploy the RMI-Servlet provided with the JDK, at the server end.
(a)
although not the newest fashion, exposing remote services with Hessian and Burlap seems to be a simple solution to avoid problem working across firewalls: http://hessian.caucho.com/doc/
see sample code for the server and client side:
http://www.javatpoint.com/spring-remoting-by-hessian-example
(b) or consider using Spring HttpInvokder (see some sample code here: http://www.javatpoint.com/spring-remoting-by-http-invoker-example)
HttpInvokder provides more customization options through the RemoteInvocationFactory, RemoteInvocationExecutor and HttpInvokerRequestExecutor strategies (for example, to add custom context information (such as user credentials) to the remote invocation, or using java’s built-in object serialization etc.), see:
http://docs.spring.io/spring-framework/docs/2.0.x/api/org/springframework/remoting/support/RemoteInvocationFactory.html
In Java, if client needs to open connection to RMI server, we need to specify -Djava.rmi.server.hostname=hostxxx to server's startup parameter,
and add hosts entry to client's hosts file like below:
x.x.x.x hostxxx
As every client need to add the hosts entry, it is inconvenitent to do so.
I am just wondering what's the way CORBA (or other RPC solution) to resolve this issue?
should they also need to modify hosts entry like RMI?
That system property is only for RMI/JRMP. I'm not aware of any way to do it for CORBA, and I've looked.
i've got a websphere 6.1 cluster environment which is composed of two nodes with 2 appservers each. Let's call NodeA including Server1(2809) & Server2(2810), NodeB including Server3(2811) & Server4(2812). Meanwhile, i created a cluster-scope datasource with JNDI local_db.
Right now i want to get database connection in a java client through WAS ORB call from above environment. The specific part of java code would look like this:
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL,"iiop://localhost:2809");
javax.sql.DataSource ds = (DataSource)initialContext.lookup("local_db");
Connection cn = ds.getConnection();
If above java client code gets run, will the database connection retrieve request follow load-balancing rule among the four connection pools of all application servers?
Moreover, if my java client gets one database connection successfully and then run a big SQL Query with large result return, as for the memory space occupation, which WAS application server would take care? only server1 due to port 2809 used above or the target server who returns the database connection?
BTW, if i put two server members for that PROVIDER_URL, such as iiop://localhost:2809, localhost:2810, does it mean load-balancing or failover?
Please help explain and correct me if i'm understanding wrongly!
Thanks
Let me start with the easy ones and proceed to the rest
Having two provider URLs' implies failover. If you can't connect to the first naming server, it connects to the second naming server and continues till the end of that list. Notice the Fail over is for connection to the naming server (not to the resource itself)
The look up is done on the server that you connect to. THe local_db represents a datasource (and its connection pool) on that server. You will one work with the server1 (as you are connecting to that NS) and will get connection from the datasource hosted on that server.
You will never get any connection from the other servers. In others words there is no load balancing (one request uses connection from server1, another uses a connection from server 2 etc). I believe this is what you mean by load balancing in your question above.
HTH
A DataSource is neither remotable nor serializable. Therefore, if you look up local_db from the server, it will return a javax.naming.Reference that the client uses to create a new DataSource instance with the same configuration as the one on the server. That also means that once the lookup has been performed, no JDBC method will ever send requests to the WebSphere server.
I was running an application deployed on a JBoss server which contained jboss-messaging deployments. The application tried to connect to a jbossmq destination deployed on another JBoss server. I tried to use different connection factory JNDI name to create the connection and got different results.
1) the connection factory is "XAConnectionFactory". In this situation, the application can successfully connect to the jbossmq destination deployed on the remote JBoss server.
2) the connection factory is "java:/XAConnectionFactory". In this situation, the connection can not be created. The exception said the destination was not an object of javax.jms.Destination.
I guess in the situation #2, the connection factory in the local JVM (i.e. the jboss holds the jboss-messaging deployments) was used to connect to the remote jbossmq destination. But I can not prove this.
Does anybody know the usage of the "java:" prefix in this case? It's better to give some references about this topic since I googled a lot but did not find the answer :)
Thanks in advance.