I am working on an enterprise application within Fuse and I'm running into an issue when the application tries to connect to ActiveMQ:
javax.jms.JMSException: Could not connect to broker URL: tcp://abc:61616. Reason: java.net.BindException: Address already in use: connect
After some investigation on the box, it turns out the Camel routes we've have deployed are taking up sometimes thousands of TCP connections which might be preventing other connections, causing the error.
However, based on what the route is doing, I wouldn't have expect it to use thousands of TCP connections to do the job. Does the way Camel and ActiveMQ communicate naturally spawn this many connections or should I see this as a major problem and investigate?
Related
I have Apache Camel application deployed on two servers and they consume from JMS endpoint. I want to make sure that only one camel route is consuming from jms endpoint at a time. The only option that I can use for clustering is using database as a lock store. Does Apache Camel provide such a feature?
I think the easiest way is to consume from a topic and not a queue.
On connection, use the same subscriptionName. Only the first connection will be allowed as far i know.
A normal webserver in a ManagedVM can listen on 0.0.0.0:8080 and properly serve requests dispatched through the GAE URL: http://xx.appspot.com:80
Instead of a normal webserver, try serving websocket connections and things no longer work. No connection gets handled anymore when connecting on: ws://xx.appspot.com:80
This (http://stackoverflow.com/questions/27827752/websocket-support-in-managed-vm) SO topic suggests exposing port 8080 to the Internet from the GCE network settings and using the IP of the GCE instance directly. That works indeed, but is not helpful as the IP changes on every new deployment.
If this is indeed the way to go, then it's not documented anywhere.
The only clue I've seen is that a Google employee also uses IP discovery to connect to the right GCE instance that hosts a websocket server:
https://github.com/proppy/cacophon/blob/master/frontend/api/controllers/DiscoveryController.js
I'm hoping for a proper fix that doesn't require me to use introspection for gather IPs of the VM instances hosting websocket servers.
With reference to Google issue tracker,
Since this thread was opened more than two years ago, I would like to check with you that if you're still hoping for the fix/FR about WebSocket server on Flex not properly exposed through GAE ULR?
for more update you can check Google issue tracker
I am still struggling with undertsanding some of Camel's main features and limitations.
My objective is to implement a demo application that can migrate camel endpoints. To achieve this everyone suggested that I should use the camel load-balancer pattern with the failover construct.
To achieve this objective people have suggested Fuse and ActiveMQ. Some have even suggested JBoss, but I am lost.
I understand that Camel needs the an implementation of a JMS server. To achieve this I can use ActiveMQ - a free implementation of a JMS server.
However camel also provies the jms-component. What is this? Is this a client implementation of JMS? If so, should I not be using an ActiveMQ client for JMS? Could someone provide a working example?
With ActiveMQ and JMS understood I can then try to find out why people suggest Fuse. I want my implementation to be as simple as possible. Why do I need Fuse? The Camel+ActiveMQ combination has the load balancer pattern with the failover mechanism right?
I am lost in this sea of new technologies, if someone could give a direction I would be thankful.
Camel provides two components. The first is the jms component, which is a generic API for working against JMS servers. The other is the activemq component, which uses the activemq API for working with activemq message brokers. The activemq component is the default component within things like servicemix/fuse, using an internal broker (not a networked/external broker).
If you are connecting to activemq, you can use either the activemq component or the jms component. The jms component will not start up a broker automatically, you would need to do this yourself.
Fusesource == JBoss Fuse == Apache ServiceMix + some addons. For argument sake, i'm going to refer to all three of these as ServiceMix.
ServiceMix is an enterprise service bus, you can lookup the term on wikipedia if you're not familiar with the concept. It uses Apache Camel to define routes between your components, implementing a number of integration patterns as you so need. ServiceMix deploys by default with Apache CXF, for JAX-RS and JAX-WS services and Apache ActiveMQ, a JMS message broker. Using Camel, you can tell service mix that when a REST API is called, do a series of steps, each step decoupled from the one before it.
JBoss Fuse (the enterprisey, costs money edition) comes with some additional components around fail over. Some of these are present in servicemix (namely, you can run servicemix in a hot stand by mode, waiting for the primary to go down). The Camel load balancer pattern doesn't really mean anything around replication, except that a message coming from one endpoint can be delivered to any of a set of a N endpoints. http://camel.apache.org/load-balancer.html
On the flipside, take a look at ServiceMix's failover http://servicemix.apache.org/docs/4.4.x/users-guide/failover.html
I think based on your question you're referring to system failure failover (needing to work against a new instance), and not a Camel Loadbalancer component (which is likely where the confusion is coming from, on the community side and your side).
start by reading these...Camel In Action, ActiveMQ In Action
Do you happen to know common application using unix socket api doesn't work on computer connected to internet router? For example, assume that there is a computer that is running a simple web server using socket in C. when a web browser in another remoter computer send a request, the web server cannot send a response to the request since its port is closed by the internet router(?) (Of course, there might exist another reasons).
However, the common applications by a competent developers works well. For example, utorrent client receives a request for some data from peers and responds to the request well, although a computer that is running utorrent is connected to the internet router. Does utorrent adjust router configurations using some system calls? If not, how does it upload the some data?
So my question is that
how does common application using socket API accomplish to forward its port, with the connection to the internet router?
How my program in C accomplish to forward its port with computer connected to the internet router?
Thank you in advance.
If you're connected the internet through a NAT router, in most cases any unsolicited connection into the router from the WAN will be refused. What you need is to tell the router (in some way) that unsolicited traffic coming in on a specific port number or range is to be accepted, and forwarded on towards a specific local IP address. This can either be done manually in your router's configuration, or if your router supports UPnP you can use that protocol to configure port mapping for the traversal of the router.
They don't. To send and receive data on the connections your program has started it's not needed. Port forwarding needs to be done by hand by the machine administrator and is only required to receive new connections.
I have an application that consists of a Windows Phone client sending HTTP requests to a Python server hosted in Google App Engine. In the GAE log, I see that I often receive multiple identical requests from the same client within a few milliseconds (see below). I never saw this behavior when testing the client in my development environment. Nonetheless I realize that this is probably error in my code, but my question is:
Can any part of the infrastructure (the mobile network, the internet, the google app engine itself) cause requests to be duplicated?
And if so, a follow on question is: are there best practices to minimize this?
No, HTTP requests are not be duplicated by the underlying infrastructure. At least they should not be.
What probably happened is that you see mobile app requests which are made in native cod and they do not use cookies and have same user agent string. The same IP is because mobile networks internally use NAT, hiding multiple (possibly thousands) clients behind a single IP address.
It's really not possible for the network to duplicate HTTP requests. It can duplicate IP datagrams with misconfigured routing, but the TCP layer filters duplicate IP datagrams so that the end to end connection only sees one TCP stream. App engine might reuse TCP ports without the standard time to wait for the previous TCP connection to die for performance purposes, but I still don't think duplicate packets would survive from the three-way TCP handshake used to initialize connections.