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 2 years ago.
Improve this question
I need to build some processes to form a distributed system.
I am in a dillema between RMI and JMS.
Issues:
I opted RMI since I already know it and it fits the distributed systems and it is fast. But the problem is that it is blocking.
I.e. if one of the other process hangs the calling process will be "stuck" on the method call. I think there are some third party libraries but I don't know if they are stable enough.
JMS is a standard and avoids the problem since it is asynchronous. But going this way I have the following issue (also I haven't used JMS before):
If I send a message to one of the processes, I sometimes (depending on the context/flow) need to know that the other process actually did something after receiving my message. But this forms a "synchronous" model, right?
So taking all these into account, what would be the best approach and how my problems would be solved in each case? E.g. my problem with JMS how would it be solved?
JMS is a better solution because of the reasons you mentioned.
Asynchronous
Non Blocking
For receiving acknowledgements you could have the receiver send you messages post some action.
The Actor model which builds on message processing concepts is worth mentioning here.
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 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 7 years ago.
Improve this question
I have a scenario where I am dealing with multiple incoming and outgoing connections. Which design pattern in java will be suitable for me to deal with such scenario.
I have multiple incoming connections like FTP, SFTP , HTTP , Database and multiple outgoing connections also FTP , SFTP , HTTP , Database. I am new to design patterns , I just want to know which design pattern best fit in my case.
I strongly recommend the Half-Sync Half-Async (http://www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf) as a general way to deal with the complexity of having (possibly) blocking communication creating asynchronous tasks that need to be executed in order to give a result back to the caller.
It is a very general design pattern so it certainly fits several client-servers protocols you cited.
ESB, suggested in another answer is not adequate to what you are looking for, since it is based on a model in which you have several processes all connected to a message bus. All those processes exchange messages and they are all typically connected to one or more message queues or message topics. Think of it as the postal service. All houses (processes) have the same role and all of them talk with the postal service in order to exchange messages.
In your problem, you have two distinct roles: a client role and a server role. Your problem seems to be how to organize the server internally, not how to coordinate servers or equal peers.
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
Generating the Thrift tutorial to Java, generates an interface Calculator.Iface where each method declares to throw a TException. Why?
Why not just keep it clean with business logic?
EDIT: I guess the motivation is to know if something happened in the Thrift invocation. So why not make it a runtime exception? Anyone has a link to a document/conversation brain-storming Thrift's exceptions?
I guess the motivation is to know if something happened in the Thrift
invocation. So why not make it a runtime exception?
One reason that could have driven the decision is that it is easy to mis-configure a middle-man message protocol (like thrift or protobuf) with the wrong file that defines a structure. Protobuf for example also throws an InvalidProtocolBufferException that extends IOException when you try to parse ByteString into a structure thereby forcing you to handle it.
I'm not a fan of checked exceptions in any form either and have debated it in various forums and discussion arenas at length. A while back, a framework I was working on needed to support multiple message protocol bindings (like thrift, json, protobuf etc). I decided to handle the checked exceptions and throw them as a RuntimeParsingException should I encounter inconsistencies between a client and server structure.
It is not pragmatic to expect a client to handle a specific message level protocol exception (by making it mandatory) when that underlying message protocol can change tomorrow.
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 8 years ago.
Improve this question
I read lot of blogs and articles that ask to take care while coding for synchronization. They ask to use concurrentHashMap, synchronizedList etc.
As per my understanding, in java web application, Application server (e.g. jboss, weblogic, tomcat), every request run under a separate thread.
e.g. I have sequence of method execution method1--> method2--> method3, then every request will have its own execution stack. Then why do we need to think more about synchronization?
Either my understanding about concurrent request is not correct or I am missing something about synchronization scenarios.
Please advise.
Because in most applications, processing a request involves accessing some shared data that may also be accessed by other threads handling other requests at the same time.
HTTP sessions are a prime example: all requests in the same session share the same HttpSession object, so if a browser sends two requests at the same time, the two threads handling those requests may try to access the same HttpSession object at the same time. You need synchronization to avoid corrupting the session.
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 9 years ago.
Improve this question
In my team we are trying to decide what path to take, if Scala (somehow unknown) or Java (very well known).
We are completely bought that our problem would be best solved by an actor type system, hence Akka but we lack Scala proficiency.
What benefits would there be to using the scala library over java library to do this project?
Akka does asynchronous I/O using Java NIO - so one thread can handle many simultaneous requests. Traditional Java server frameworks use one-thread-per-socket I/O. So, if you need your code to scale to, say, 10K open connections on a single VM, without needing to spawn 10K threads to do it, then you probably want something asynchronous.
There are Java-language frameworks such as Netty or Atmosphere which also do asynchronous I/O - so you don't have to use Scala if your team is already adept at Java.