Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the best practices to have two applications on the same host, one J2EE and the other Java standalone, communicate one with the other?
More infos:
The j2ee application will be deplyed in Wildfly AS
The Java stand alone is a Netty NIO Server
EDIT ONE
Even more infos:
The Netty server is a cardgame server that will hold the business logic for the game itself and will allow players to play synchronously one with the other (up to four players per game, up to a max amount of games allowed from my hw server resources)
The J2ee application (deployed in Wildly) will take care of authentication&authorization
The J2ee application will take care of the DB connection and Persistence
The J2ee application will have to forward to the java standalone server the remote-socket-address of the authenticated player and eventually an object holding the state of that player
The J2ee application will potentially be the one triggering the communication although for my current flow, i am in need of a full duplex communication from both ends (hence my fear about a WS or Rest, isn't it kind of asymmetrical for a full duplex communication channel?)
The Netty server may be seen as a background task of the AS that will start it (and eventually other cardgame servers) in an attempt of pseudo horizzontal scalability
Have one open a socket and communicate to the other.
You could do more exotic stuff, but if anything about the environment changes, it will break. For a few ideas of "exotic stuff"
Write and read from named pipes
Set up a shared memory buffer, or two.
etc ...
I think it is not possible to give a good implementation pattern when you are not clear/explicit about the following relevant questions:
Is the standalone application a background task (possibly launched
with the container)?
If yes, do both J2EE and standalone have to
share session or conversation data?
Who triggers the communication
when communicating?
Do both applications possibly share the same back-end database?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In an enterprise back-end Java application, I have a requirement where some part of code calls various API which are independent of each other. On receiving response, I am utilizing them and passing data to requester.
For this, I have implemented callable based multi-threading (using Executor). But a colleague is stating that implementing multi-threading would make my code responsible for managing resources and not the Web App Container which can lead to performance issues.
So I wanted to know, what is the impact of implementing multi-threading in my code? And how can I make sure that resources are managed properly without impacting overall application.
There are a some different aspectes mixed together in your question. Creating threads on an application server is not prohibited because it could cause performnce issues. It's more that the server itself is responsible to manage the system resources. Spawning own threads, of which the server is unaware of, can not be managed by the server. See this page for more info about the topic.
Using an thread-executor that is provided by the platform, is very valid an could be used to implement multi-threading nevertheless. See here for example.
Another aspect of multi-threading is indeed performance. Creating threads comes with a certain cost and creating too many of them may lead to an overhead in conext-switching. The trade-off between pralellism and having to manage a lot of threads has to be consireded by the developer. Again this is why application servers, manage their own thread-pools.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've in the past created client-server web applications using Javascript, AJAX, Node, Express and MongoDB, but now I'm required to creare a client-server desktop application. It will therefore basically consists of a desktop program which will connect to a server program by doing requests. The server program will respond to the client program with the requested data which it can fetch from the database.
Since I'm really new to these kind of applications in Java, I have no idea how to create such an application in Java. Since the project will be large, we cannot hard-code all the server. We need probably a framework on the server side that listens for requests, but I've not found any for now. For example, Play Framework seems only to work for web applications. Which frameworks are useful for these purpose? Is this the right approach for this kind of applications? How would I connect client and server applications?
Please, do not suggest "use sockets". This will be quite a big "serious" project, and we need high level tools. We don't know how usually these kind of projects are created. Please, explain a little bit which patterns are usually used. Examples of concrete programs, maybe with open source code will be useful for us to understand. Also a list of the requirements that we need for these project would be very useful.
Note: I'm not asking for a exhaustive list of frameworks that we can use. I rather asking which kind of tools (with concrete examples) should we use and how to combine them. How to structure such a project.
You could write the server side application in Node JS or whatever other server side language you prefer - and implement that using REST services. Then in your Java desktop application, it would just communicate with the server using HTTP REST / SOAP etc.
That way if you were to then want to swap to use something like .NET to make your desktop application you would be free to do so without it changing anything on the server side. Also you would be able to implement a mobile application / tablet app / other web application and reuse all of the server side implementation easily without changing anything server side.
Another option is to use ServerSocket for the Java server side, and then connect to that from the client but you seem to know and dislike that option.
Another option to connect each side of the application would be to use some kind of pub / sub middleware messaging service - check out JMS as a framework - you will need some kind of implementation of JMS such as Active MQ, Websphere MQ or one of the many other free implementations. Check out : http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html
Difficult question to answer, but those are 3 high level options.
Use web technologies to connect client to server HTTP REST, or SOAP
Use ServerSockets and Socket connections and do everything manually
Use a messaging framework such as JMS
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In building java chat application, is Web Service better to use than JMS, RMI, or Socket programming?
My VPS has the ff: 512MB Memory, 1 Core Processor, 20GB SSD Disk and 1TB Transfer.
My target number of users in the same time is, 5-30.
I think the way to handle the changes in chatbox is using Polling.
Is my VPS can handle that load if I am using web service?
If I am going to use other technologies like RMI or JMS?
Is my VPS can handle it?
If you have a web frontend for your chat, using websockets (if you want to use java on the backend, it's supported by jetty but also by other http servers) instead of polling is a more common approach.
Definitely no JMS,RMI or sockets, if the client is a browser, if it's a desktop client using something based on sockets and a custom protocol could be the easiest way to go.
The number of connections your VPS will handle is dependant on many factors, included how performant your application will be.
You should give node.js a try. Search for "node.js chat apps".
Node.js chat server app is going to have very little memory footprint giving you more memory for the server at runtime.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I choose java to make my web application with maven + hibernate + spring MVC + apache tomcat server (Java EE).
My web application will have many users and many visitors every day.
But my friend told me that web application with java don't support a lot of connections and it's made just for Intranet and business application with network within an organization.
So is it true apache tomcat can't handle all that traffic ?
i'm not looking for who is the best between java, php and .NET i want just know if web application with java can handle a big traffic ?
also explain me if there is some other negative points of using java and apache tomcat server.
The Java based technology stack you describe is extremely scalable, if you want it to be, and I would have no worries about using it for high traffic applications.
You may want to look at distributed hosting and load balancing, to make things more reliable. Lots of high traffic applications use Java and Spring stacks.
using plain old jsp/servlets are faster than spring and hibernate because spring or hibernate have a middle tier with classes which renders the page slowly and takes more memory at the server.
For production environs with huge scale applications you will end up writing plain jsp/servlets as they are a breeze to write and maintain.
Also i would like to add that struts library(jar file) had some security vulnerabilities in late 2013 only. Stay away from Struts and Spring.
People may be down voting but there is truth behind what i have actually experienced.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We are developing a flash game with flex as client and java as server. For the communication between client and server we are planning to use BlazeDS. We are hoping that hundreds of thousands (maybe millions) of players will play the game concurrently but we find out that we would have problems on scaling because of the BlazeDS's limitations on the number of clients it can handle. We are not able to afford LCDS, and heard that GraniteDS does also have limitations (higher than BlazeDS but still not enough).
Would deploying our application to a PAAS such as Amazon Elastic Beanstalk solve this scaling problem considering the Blazeds's limitations?
To summarize very quickly
With BlazeDS you have a limitation of a few hundreds connections per server.
With GraniteDS you have a limitation of a few thousands, possibly a few tens of thousands connections per server depending on your use case, size of payload, etc. (in fact the actual limits are those of the app server asynchronous I/O support, tomcat, jetty or whatever).
Using clustering (on a PaaS or wherever) would bring you to much higher numbers (not sure you can get to millions though).