In the 12 Factor article on Port Binding
http://12factor.net/port-binding there is a requirement that every app
be self-contained and not have a runtime injected e.g. Tomcat. For
what reason is this advised... what are advantages of self-contained apps for microservices?
To understand rules around port binding and self-contained apps, it's helpful to view things from the perspective of the platforms designed to run 12-factor apps, like Heroku or Deis.
These platforms are scaling applications at the process level. When processes are scaled up, the platform tries to place these additional workers behind the routing mesh so they can start serving traffic. If the app is not self-contained and, for example, is tightly coupled to a front-end Apache server using mod_jk -- it is not possible to scale by running more isolated worker processes.
Port binding exists to solve the problem of "port brokering" at the platform level. If every application worker listened on port 80 there would be conflicts. To solve this, port binding is a convention whereby the application listens on a port the platform has allocated -- and which is passed in as a $PORT environment variable. This ensures a) the application worker listens on the right port and b) the platform knows where to route traffic destined for that worker.
I think is because it gives you a great deal of flexibility when the time to scale up your app comes. If you use tomcat you'll have to copy your .war and drop it inside another tomcat and then load balance your requests to either of them.
Instead If your app has a self contained http server, you colud just run another instance in another port and forget about all that tomcat stuff. You would still have to load balance your requests to either of your app instances, but seems more straight forward.
Related
We have an application on our WebSphere Application Server that calls a web service of a second application which is deployed on the same app server.
There are 100 available web containers (threads).
At times when there are many active users, application 1 allocates all available web container threads. When application 1 tries to call the web service (application 2) there are no free threads, so application 1 never finishes and therefore the whole system hangs.
How can I solve this? For example, is it possible to restrict the web container thread count per application? For example, I would only permit application 1 to use 50% of available threads.
A solution would be to add some code to application 1 that watches the count of requests being processed simultaneously. But I'd try to avoid that if possible, because I think this is very error prone. Earlier, we used the synchronized keyword. But that only allows 1 request at a time which caused even bigger problems.
It could be possible by defining separate transport chain and thread pool.
I dont have web console before me, so steps in rough order:
create separate thread pool for your soap service app
create separate web transport chain on new port e.g. 9045
associate that thread pool with transport chain
create new virtual host, with host alias *:9045
map your soap-service app to that port
If you will access app via 9045 port it will use your own separate thread pool for that.
Concerns:
if it is only local access (from one app to the other) then you just access it via localhost:9045 and you are good to go
if your soap service needs to be accessible ALSO from outside e.g. via plugin with the default https port (443), you would need to create different DNS hostname for that so it can be associadet with you soap sercvice app eg. soap-service.domain.com (and then you use that domain in the host alias instead of *. In that case plugin should use that 9045 port for transport also, but I dont have env at hand to verify that.
I hope I didnt complicate it too much. ;-)
I have a Java Application(works as server for a client application) with a GUI. This application has to run always even after restarts of the server.
I have created a windows service using Apache daemon for this purpose.
When the server starts I can see my services running as system service. But when I open the GUI of the application another instance starts.
I need the GUI to be attached to the same instance which started after restart, is this possible.
A Windows Service (as well as daemons on Unix-systems) can't run with a GUI because it starts without a Window Management System like Windows Desktop or KDE, Gnome, etc. I'm actually surprised that your application starts as a service because attempts to start GUI-elements should lead to an error.
You have to separate the GUI from the server components. The GUI then needs to communicate with the server by some protocol. Because you already have finished your application I suggest RMI as protocol of choice, that should be the easiest to implement because you essentially just have to add some interfaces to your classes to get RMI on its way instead of adding a complete layer of complexity by your own (an additional server to receive commands from the client, etc.).
RMI can be set up to only listen for connections from localhost, so in terms of security you should be good as well.
My goal is to have web servers that work on the default port so users don't have to type in a port #. Easy to do with LAMP stack, where A is apache... and no other web server exists. However, if I purchase general purpose hosting with Centos and I want to run
1) Gunicorn/NGINX for Python/Django -> access from example.com from outside (no port required to be entered by the web browser.
2) Spring framework in a Java EE container - Java EE defaults to port 8080 and other ports in that range but people just enter a domain name and expect it to work. -> So reachable from example2.com
3) Node.js - Reachable from example3.com
4) PHP apps such as WordPress, Drupal on LAMP - example3.com
Recommendations are appreciated.
My closest experience that seems to do this for example would be AWS with load balancer allowing access from public web - app servers accessible from only load balancer.
Thanks,
Bruce
You can use nearly any http server in front to do this kind of job.
bind everything (tomcat, nodejs, gunicorn, uwsgi, etc. pp.) to local http or file sockets and use the proxy feature of your favorite server to bundle them all on this host. With the naming of nginx: use different locations on one server and/or different server blocks with proper server names set to build your custom host.
A few servers:
nginx with proxy feature
apache2 supports setups like that, too if you use mod_proxy.
haproxy is another alternative
Finally it depends on your specific needs (and experiences) which setup to pick.
Edit: missed docker a little - but the same thing works for containers - except that you do not use file sockets, but make everything with (http) sockets in private or public nets.
I'm new-ish to networking, and I'm swimming (drowning) in semantics.
I have a VM which runs a Java application. Ideally, it would be fed inputs from the host through a RabbitMQ queue. The Java application would then place the results on another RabbitMQ queue on a different port where it will be used by the host application. After researching it for a bit, it seems like RabbitMQ only exists in the localhost space with listeners on different ports, am I correct in this?
Do I need 2 RabbitMQ servers running in tandem, then, (one on the VM and other on Host) each listening to the same port? Or do I just need one RabbitMQ server running while both applications are pointed to the same IP Address/Port?
Also, I have also read that you cannot connect as 'guest/guest' unless it is on localhost, which I understand, but how is RabbitMQ supposed to be configured/reachable to anything besides localhost?
I've been researching for several hours, but the documentation does not point to a direct answer/how-to guide. Perhaps it is my lack of network experience. If anyone could elaborate on these questions or point me to some articles/helpful guides, I would be much obliged.
P.S. -- I don't even know what code to display to give context. Let me know and I'll edit the code into the post.
RabbitMQ listens to TCP port 5672 on all network interfaces out-of-the-box. This includes the "loopback" interface (to allow fast connections to self) and interfaces visible to other remote hosts (including VMs).
For your use case, you probably need a single RabbitMQ instance for both directions. The application on the host will publish messages to one queue and the Java application in the VM will consume messages from that queue and push the result to a second queue. This second queue can be consumed by the application on the host.
For the user, you need to create a new user with the appropriate rights. This is documented in the access control article. To create the user, you can do it from the management web UI (after you enabled the management plugin) or using the rabbitmqctl command line tool.
The last part is networking between the host and the VM. It really depends on the technology you use. It may work out-of-the-box or you may have to configure how VMs are connected to the network. Refer to the documentation of your hypervisor.
I created a game and I want to put it on online. I want to buy a website (I'll probably use goddaddy to buy a domain name and use them as the web host) to use as the server to handle game play. Because I would need a separate server for each game, I would need each game's server to exists on different ports. So this leads to my question, is is possible to access these ports on my future web server? (I wrote the program in Java, so I would assume that I would access the ports from the server side by choosing a port for a ServerSocket, and from the client side by using the IP address from the website and the chosen port for a Socket)
(note: also, I am aware that it may be easier to simply use one port and run the servers on different threads instead, but I am just curious to have my question answered)
thanks a lot,
Ian
Technically it is possible to use different ports, but I don't think that a webhoster like goddaddy will let you run a java process that binds to a special port.
If you mean that you are going to create your own TCP server you obviously can create as many instances of your server and configure them to listen to different ports. But it is year 2011 now. This solution was OK in early 90s.
I'd suggest you to use Restful API that works over HTTP. In this case you can forward calls to server side of each application using URL, e.g.
http://www.lan.com/foo/login?user=u123&password=123456 - log in into application foo
http://www.lan.com/bar/login?user=u123&password=123456 - log in into application bar
In this case you need only one server (the web server) that is listening to socket (port 80).
Your server side implementation could be done using various web techonlogis (php, java, asp.net etc) on your choice.
Yes, that should work. The security manager permits connections to a different port on the same IP address that the applet was loaded from.
You can run a Java server on whatever port you want. Each server will accept incoming requests on one port.
The correct way is simply run on one port and each connection will instantiate a new servlet instance (which happens to run in its own thread) that can then service that request. You usually don't need to run separate ports or worry about concurrency, especially if all the stuff that's shared between connections (e.g. multiple players in one game) is handled through database read/writes.
Your host (GoDaddy) will have to allow you use of those ports, but if they are providing proper hosting (not virtual hosting) and given you your own IP there's no reason why you shouldn't be able to.
Your solution may work theoritically, and I like AlexR's solution. But providers like godaddy doesnt let you run a java server, on ANY port. You will need to find out somebody who does. What I found is the cost goes up from $5/mo to about $20/mo, but you get a much better (read faster) machine. Good wishes, - MS.