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.
Related
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 have a Windows service written by another developer who no longer works with me. It was written in C# with .NET 4.5 requirements. Our solution is making the move to Linux and the daemon naturally needs to be converted.
My dilemma is what to rewrite it in? C++ or Java? The daemon is not complicated. It's simply a controller for our other applications to ensure if they crash or are killed they are restarted. Aside from that it performs health checks through a named pipe and is controlled via a password protected web socket via a separate management Tomcat web interface and writes all of it to logs.
Please put aside any suggestions of "write in what you're most comfortable with" I have a fair amount of experience and knowledge in both languages, and I'll learn whatever else I need to as I go. My concern is the feasibility and effort to accomplish everything I need. I don't have any particular time constraints, but if one language is a fraction of the time of the other then maybe that's a better solution.
Writing it in Java looks like the easiest solution currently, but writing it in C++ has the advantage of being native no-frills code. However, I haven't ever written any web interface or socket code in C++ before, so I do not know the effort involved with that.
To break down my requirements:
Linux
Web interface for control
Named pipe for communicating with client applications
Existing code needs to be heavily refactored
Is C++ or Java more appropriate?
Edit: added more info
Edit2: I guess I should have mentioned that the code needs to be heavily refactored anyways. It was originally written in such a way that renders it difficult to make changes and additions. So rewriting is a cleaner solution at this point. As I mentioned, it's not a large program. Just a controller service.
Porting the solution to .Net Core may the way to go. It will run on Linux (and Mac for all intents and purposes...) and most of your codebase may need minimal refactoring. The only concern is if .Net Core currently has the features you would need supported in the app. And, .Net Core is still in preview.
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 have one question about how to construct app with vaadin and rest to gain good performace and scalability. I want to make rest api as a business layer and vaadin as ui for web. Ive made this decision cause my app will be also available as standalone version and on mobile os (ios and android). For me this idea is good if we are speaking about scalability but what about performance. Lets take about 5 thousand concurrent users for example.
I want to know general data about performance and will it be good for a lot of concurrent users. Only vaadin is hard to gain good performance with a lot of concurrent users (cause anyway almost all the code is running on the server). And if we also add rest api for any vaadin operation inside im scared that i will gain fatal combo.
Of course vaadin and rest api are located on the same server.
What do you think about it? Thanks a lot for answers.
I don't think it is a good idea, as Vaadin is a server side framework, so every action you do goes to the server, and from there on it has to make another rest service call to another server from where you have to get data and render it. I would rater suggest you to try some client side frameworks like ExtJS, Jquery, Angular JS, GWT etc... You render your UI on the client side using these frameworks and any action which requires data ops like fetching data or perform transactions you can make a rest service call to the server side. Using this approach you can avoid another redirection.
Now a days you the concept of RWD is getting popular, I think this would be a great choice for your use case. Build once deploy on any device :)
BTW, this is purely my opinion.
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 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.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
how to use JNI in JSP page?.In net i found that
1. because if anything goes seriously wrong in the C part of your application, it will very likely crash your J2EE server, downing all other web services and applications it is running.
because the 'reactivatable' nature of web applications means there is no guarantee that a static initializer will not be executed more than once during one JVM run.
Unless you're confident of the reliability of your JNI-linked library, I'd strongly recommend not doing this, for the reasons you've identified.
I'd recommend decoupling the application server from your native code, and make the native library available via some remote mechanism (e.g. web service / REST / simple socket). That way you've isolated the app server from any fatal problems related to the native code.