What is the best way to make a standalone java server built using J2SE Socket API high available? Using an HTTP server would have been a good choice specially for the built-in features e.g. security, clustering, transactions, etc. but the server should be capable of accepting TCP/IP socket connection from java & non-java clients (mainly legacy). Tomcat does not accept non-http TCP/IP requests? Moreover this post points out servlet for implementing socket connection it's not a good practice. What would be good approach?
After exploring online, this is what I have compe up with. A standalone java application can be made high available by using a combination of the following:
2 VM deployed with HAproxy and keepalived to form the highly available load balancing layer.
Keepalived will keep the load balancers in active-passive mode and the HAproxy will forward the requests to a cluster of backend socket based java server apps
At least 2 VM deployed with the custom socket based java server apps. The HAproxy servers will distribute the requests over these 2 VMs
Use at least 2 terracotta server to share the java server apps. Terracotta will provide the sharing of the memory and help the custom java servers to scale.
Use MySQL NDB Cluster for the database.
Any suggestions?
Related
I have read up on web sockets providing full duplex connections over TCP which can be used in scenarios where long polling was used to get live updates to client from server. Now I have a Tomcat based application which serves multiple REST based web service response, and I want couple of API's to be implemented using web sockets say to render dashboard with latest data where multiple users are working on them concurrently, is that possible ? My concern here was even if the connection was upgraded to TCP from HTTP wouldn't web socket require a separate port to run than the default Tomcat port 8080. In that case should I house the Web Socket based endpoints separate to the Tomcat based application already running. Please do correct me if any of the above is wrong.
A couple of month ago, I wrote a small Spring Boot webapp with embedded Tomcat that provides both, REST endpoints and websocket support, and both via the same port. So, yes that works... if you wanna sneak a peek: https://github.com/tommybrettschneider/pinterest-boot
Besides that, this post should also clarify things:
Shall I use WebSocket on ports other than 80?
I would like to create a web service with GoLang that runs either on IIS (7, 8 or 10) or under Tomcat 7.0. We have multiple environments, each with multiple servers, all being Windows 2008 R2, 2012 or 2016. All servers are private (10.x). My goal is to add some REST services to a COTS product that uses both IIS and Tomcat. I'd prefer to avoid gluing nginx or something else onto either server at the risk of impairing the COTS product or having their tech support people not answer the phone. Again .. the servers are only accessible via corporate VPN and are not public internet-facing.
Which server would offer the easiest path to get something working -- Tomcat or IIS?
That's not really about Go, but still there exist at least two solutions I can think of:
Reverse proxying of HTTP requests.
Write a plain Go server serving requests via HTTP.
Maybe turn it into a proper Windows service using golang.org/x/sys/windows/svc.
Deploy it.
If it's to be hosted on the same machine which runs IIS, then it's fine to make it listen on localhost only. Note that it will need a dedicated TCP port to listen on, and you'll need to make it possible for your server to be somehow configurable in this regard.
Set up reverse proxying in your IIS so that it forwards requests coming to whatever (part of an) URL you want to the Go server.
Use FastCGI.
Go supports serving requests over the FastCGI
protocol by means of its standard library,
and IIS suports FastCGI workers.
So it's possible to (re-)write your Go server to use FastCGI
instead of HTTP and then hook it into IIS via this protocol.
The pros and cons of these solutions—as I view them—are:
Serving over plain HTTP is more familiar to a developer and
makes the server more "portable"—in the sense it will be easier to change its deployment scheme if/when you'll need it.
Right to making it available to the Internet directly.
Conversely, with FastCGI, you'll always need a FastCGI host as a "middleware".
There were rumors that HTTP code is more fine-tuned in terms
of performance than that of FastCGI.
Still, this only will be of concern for reasonably hard-core loads.
One possible upside of FastCGI over HTTP is that it can
be served over pipes rather than TCP. For instance, you might
get it served over named pipes as it's supported by IIS's FastCGI module and there exists 3rd-party packages for Go implementing support for them
(even including one from Microsoft®).
The upside of this is that pipes are beleived to incur lesser overhead for data transfer (basically it's just shoveling bytes between in-kernel buffers belonging to two processes instead of pushing them through the whole TCP/IP stack), and using pipes frees you from the need of dedicating a TCP port to the Go server.
Still, I have no personal experience with this kind of setup and its performance trade-offs.
I have started using Mobicents (aka Restcomm) sip servlets with Wildfly 10 but even i could not find a clear answers in documentation or anywhere else for questions i have below.
1) Do sip servlets support standalone-ha model such as in a sip dialog fail over scenario? For example in an established call, if node one fails will node to accept subsequent invites or return a 404 like response .
2) Is it required to use Mobicents (aka Restcomm) load balancer even if there is a sip load balancer in front of the servers ?
3) Does the sip application configuration,code etc.. change between standalone and standalone-ha mode? Or it is handled by Wildfly, ActiveMQ, Infinispan?
Thanks
1) Restcomm SIP Servlets on Wildfly 10 doesn't support replication yet. Only Restcomm SIP Servlets on Wildfly 7 supported product from TeleStax supports replication, Wildfly 10 is expected to be supported later this year.
2) Nope but you need to make sure your load balancer can support SIP Session affinity to always route messages from a given dialog to the same node.
3) No changes should be needed to the application. Only be conscious of what you replicate as it adds overhead in terms of network traffic and memory usage.
I am going to write a service to manipulate a database that all Insert/Update/Delete/Select will be executed via this service.
However, I only know socket services (Web service is a kind of socket service because it uses network layer).
What I am concerning is the performance of socket services. Because they needs to go through the network layer. So OS needs to start the network layer and then pass all packets to my program that maybe have performance overhead on network layer.
So my question is: is there any non-socket services working in both Windows and Linux?
Updated at 19th January 2012
I found the solution here: http://en.wikipedia.org/wiki/Inter-process_communication
Is this over the network, or on same box?
If over the network, sockets are fine, WCF, web services are all fine (this is how SQL Server, Oracle and everything else work...)
If local, same box, you can use a shared memory approach, and avoid the network completely.
FWIW, Shared Memory totally works on Windows. See CreateSharedMemory function from Win32-SDK. In .NET, you can use .NET remoting with shared memory as the transport. There are many ways to do this on Windows.
It seems that both service and server refer to some web based application. But is there any precise definition of the two terms?
A server offers one or more services. Server is also a more technical term, whereas service is more a term off the problem domain.
You also need to distinguish between:
Server as hardware (see post from Dan D)
Server as software (eg. Apache HTTP server)
You can find more elaborate definiton on Wikipedia:
Service
Server
This is regardless of client-server or P2P models.
A server provides services to one or more clients, and a server(hardware) is a computer. A server(hardware) can be anything from a home computer to a big server-rack with a lot of processor power.
From the view of a computer, a server(software) is just a set of services which is available to clients on the network.
Some well known services are web-server, mail-server. ftp-server. notice they are called xxx-server because such programs consist of a client and server part. The postfix is mainly to distinguish whether we are talking about the client or the server.
So at what moment do we call something a server? We do it when a computer shares some service/content on the network, which is accessible by clients. In other words, when we make a server as defined for software.
Regarding the P2P model: every one is both a client and a server, hence called servent. The above apply to the server part of a P2P network, just remember that it also can be a client.
Futher reading:
Client-Server model
P2P
a server is a piece of hardware or on a virtual machine
a service is a process that provides services normally over the network and runs on a server
but a server can also refer to a web server which is actual a service but it's sort of like one as it hosts services
i think those are reasonable working definitions
I think a simpler way to define both besides the definition of the server being a piece of hardware, a server in the software sense is a service that serves data. In other words you interact with a server with a request and you should get a response back. It "serves" data.
A service does not need interaction and is pretty much just a random process that keeps running doing the same thing, but a server is a service because it is basically a process that keep waiting for a request to come in so that it can return a response.
"A service is a component that performs operations in the background without a user interface."
~ Android Developers
Services don't just run on servers
Shell services
Services can run from the shell. Unix refers to services as Daemons (pronounced "demons"), and Windows refers to them as services.
Client-side services
Services can run client-side. Mozilla (and other browsers) support Web Workers which run in a background thread. Client-side frameworks, like Angular, support services as well.