So i wrote a program to connect to a Clustered WebLogic server behind a VIP with 4 servers and 4 queues that are all connected( i think they call them distributed...) When i run the program from my local machine and just get JMS Connections, look for messages and disconnect, it works great. and by that i mean it:
iteration #1
connects to server 1.
look for a message
disconnects
iteration #2
connects to server 2.
look for a message
disconnects
and so on.
When i run it on the server though, the application picks a server and stick to it. It will never pick a new server, so the queues on the other servers don't ever get worked. like with a "sticky session" setup... My OS is Win7, and the Server os is Win2008r2 JDK is identical for both machines.. How is this configured client side? The server implementation uses "Apache Procrun" to run it as a service. but i haven't seen too many issues with that part...
is there a session cookie getting written out somewhere?
any ideas?
Thanks!
Try disabling 'Server Affinity' on the JMS Connection factory. If you are using the Default Connection Factory, define your own an disable Server Affinity.
EDIT:
Server Affinity is a Server-side setting, but it controls how messages are routed to consumers after a WebLogic JMS Server receives the message. The other option is to use round-robin DNS and send to only one hostname that resolves to a different IP(Managed Server) such that each connection goes to a different server.
I'm pretty sure this is the setting you're looking for :)
Related
I have a Windows application (written in Java) that connects to the server (spring + httpd) via websockets. Another websocket connection is established as soon as a user authenticates to the same server from a web browser. If server notice that both clients have same IP address, it "pairs" them so both applications can talk with each other.
The challenge I'm facing currently is that when multiple Windows application are starting up, all of them establish new websocket connections that exceeds httpd limitation of 255 active connections and the server goes down.
I'm looking for some feasible solution that would not overwhelm the server. A perfect scenario: a user logs into the system using a web browser, the server tries to connect the Windows application running on a clients machine afterwards and everyone is happy.
Have you any idea how to achieve it?
What I've tried already is to not create a new websocket connection on the Windows application startup but send a GET request to the request to the server and wait for the response that will occur after authenticating a user from a web browser. Hanging GET requests still need resources and httpd keeps a separate process for each of them. Also, it turned out that httpd has a 5 minutes timeout for hanging requests and sends 502 back after reaching it out.
I thought that maybe it is possible to handle GET requests in Spring by only one process / thread, but I haven't found any info for that.
Another limitation worth noting is that the Windows application runs on customer machines and customer's security policy may not allow for any wise tricks.
I am connecting from server 1 to server 2 using ibm mq series(single queue manager group) using single subnet NAT ip address. Destination of server 2 is single ip address point. Problem is: whenever i connect different custodian data(client data) to upload data and whenever server restart happens on one custodian point, other custodian client resets and not able to connect to server2 ip address.
Solution i have attempted: instead of ibm mq series and regular c# code, using combination of microservices with java8 parallel processing and Apache Kafka to render parallel threads to connect with single nat ip subnet, so that none of the custodian codes get resetted.is this solution correct? But the destination server is giving single ip address point to connect for n custodians. Is there something i can do in nat gateway to parallel render data to destination IP address? Please help me with my solution.will be happy to help with any info.
Your question is not very clear and then you go off on a tangent about your solution which again is not clear and appears to be creating an overly complex system.
So, let me guess what your setup is:
Server 1 has an IBM MQ client running a C# .NET application. Is this correct? If so, what version is the IBM MQ Client software? i.e. 9.1.0.9
Server 2 is running IBM MQ queue manager. Is this correct? If so, what version is the IBM MQ Server software? i.e. 9.2.0.4 Use the dspmqver command to get this information.
If the above is correct then it is pretty much a basic IBM MQ environment.
So, when your application has this issue, MQ would have thrown an MQException. What was the Completion Code and Reason Code? The reason code would probably been one of the following
2009 [MQRC_CONNECTION_BROKEN]
2059 [MQRC_Q_MGR_NOT_AVAILABLE]
2538 [MQRC_HOST_NOT_AVAILABLE]
What did your application do when it received the MQException? Crash or die or loop forever?
Did you add reconnection login to your code to reconnect to the queue manager after the failure?
I have a Hazelcast client application which will sometimes be started before any server in the cluster. Before I start building this myself.
Is there any built in support in Hazelcast to make the client wait for the cluster to start up and then connect to it?
Yes you can set the connectionAttemptLimit on the ClientConfig.
connectionAttemptLimit: the maximum numbers of times to try the addresses
to connect to the cluster, defaults to 2. When a client starts or a the client
looses connecting with the cluster, it will try to make a connection with one
of the cluster member addresses. In some cases a client can’t connect to these
addresses, e.g. the cluster is not yet up or not reachable. Instead of giving
up, one can increase the attempt limit to create a connection. Also have a
look at the connectionAttemptPeriod.
I found this and it worked for me:
<hz:network connection-attempt-limit="50"
connection-attempt-period="5000"
connection-timeout="1000"
redo-operation="true">
<hz:member>
My system has the following parts:
ActiveMQ broker exposed on tcp, port 61616
3 Grails/Spring wars that live in their own Tomcat servers, they publish and consume messages to the JMS broker
n times remote client system with a JMS listener component to receive client specific messages, connect to the JMS broker through VPN using a hostname and port 61616
So far, all works fine throughout dev, Test and production environments.
We've just connected a new client system in production and we've noticed that it's logs start to report 'channel was inactive for too long' exceptions and drops the connection.
Worrying the overall effect of this one client is that it stops all message consumption on the broker so brings are whole system to a halt.
This client listener (using Spring caching connection factory) appears to connect to the JMS broker ok, process some messages, then 3 mins reports the exception. Turned on DEBUG in ActiveMQ and got loads of output, nothing suggesting a warning or error on the broker around the same time though.
Believe that ActiveMQ has some internal keep alive that should keep the connection even if inactive for longer than the default 30 seconds.
Infrastructure guys have monitored the VPN of this client and confirm it stays up and connected the whole time.
Don't believe it is code or Spring config that is at fault, as we have numerous other instances of the listener in different clients and they all behave themselves fine.
Suppose I have 2 questions really:
What is causing 'channel inactive' exceptions?
Why does this exception in a single client stop ActiveMQ from working?
EDIT - adding exception stacktrace:
2013-04-24 14:02:06,359 WARN - Encountered a JMSException - resetting the underlying JMS Connection (org.springframework.jms.connection.CachingConnectionFactory)
javax.jms.JMSException: Channel was inactive for too (>30000) long: jmsserver/xxx.xx.xx.xxx:61616
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1833)
at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1850)
at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
at org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:126)
at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:101)
at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFormatNegotiator.java:160)
at org.apache.activemq.transport.InactivityMonitor.onException(InactivityMonitor.java:266)
at org.apache.activemq.transport.InactivityMonitor$4.run(InactivityMonitor.java:186)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:693)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:719)
at java.lang.Thread.run(Thread.java:813)
Caused by: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: jmsserver/xxx.xx.xx.xxx:61616
... 4 more
Have you tried the following:
Disable the InactivityMonitor; wireFormat.maxInactivityDuration=0 e.g.
URL: tcp://localhost:61616?wireFormat.maxInactivityDuration=0
If you don't wish to disable, have you tried setting it to a high number e.g.: URL: tcp://localhost:61616?wireFormat.maxInactivityDuration=5000000 (just an example - use your own time in ms)
Also, ensure that the jar files are the same version for both client and server.
Hope it helps
You just need to change the activemq.xml (configuration file):
transportConnectors section:
transportConnector name="ws" uri="ws://0.0.0.0:61614"
change
transportConnector name="ws" uri="tcp://0.0.0.0:61614"
It works for my windows and linux virtual machines
first of all, I am not very familiar with Tibco, please keep that in mind ;).
I have a task to write an application which reads/writes to a jms queue (not a big deal). The problem is, the customer uses Tibco & allowed me to connect to their server to run some tests. Unfortunatly, I am only allowed to connect via natted IPs & as soon as I try to connect to a QueueConnectionFactory, I receive an error because Tibco itself tries to connect to the "private" IP.
The interesting thing is, receiving the Queue, QueueConnectionFactory,... objects from the context works fine - but when I do a toString() I see that the cf received has configured the 'private' IP.
Example: I set this url as provider url -> tibjmsnaming://213.133.111.182:7222
Receiving the QueueConnectionFactory object works fine, doing a to string returns "QueueConnectionFactory[URL=tcp://145.12.51.4:7222;clientID=null]"
So as soon as I call "createQueueConnectionFactory()" I receive this exception:
javax.jms.JMSException: Failed to connect to the server at tcp://145.12.51.4:7222
Is there a way to override this behavior & tell the Tibco server to use the configured provider url instead?
I know this is ancient, but if you - like me - come from Google, here's the correct answer:
the URL above uses JNDI to look up the actual connection; the connector does not directly connect to the NATted IP, but connects to the NATted IP (213.133.111.182) to look for the "real" IP (145.12.51.4), which doesn't work due to the NATting.
Solution: either change the registered IP in the JNDI store or connect directly, circumventing JNDI.
1) Check from the client machine, if you are able to ping the EMS server IP
2) Check if you can connect to EMS IP:Port via Telnet
3) If both succeed then your EMS client should connect to EMS Server, if still it is not connecting, then you 4) must review the EMS DLL is proper is at least able to connect when u run the EMS client and server from the same machine. 5) if point 4 is successful then you must review the client firewall and server firewall policies with your network admin.
-hB
The only way you're going to be able to directly send ad hoc messages to a private port is if the firewall / router that is doing the NAT is configured to pass through messages on that port to the correct destination. Otherwise they'll go nowhere.
I think you would have to investigate if JMS or Tibco has a mode that allows a client to maintain a connection to the server or poll the server for messages because it will not be able to receive ad hoc messages in the other direction.
In extreme cases (e.g. corporate firewalls & proxies where all ports are offlimits) the client might not even be able to connect to your server on some random port. It might have to open a connection via an HTTP/1.1 pipeline to receive any messages from your server.