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 a server (Linux/Apache-Tomcat & MySQL) which hosts several almost identical websites. At least, the java libraries are identical.
Right now, every website has it's own .jar file with these java classes.
I'd like to know if this is a good practice, or if I should have these classes in one place where each of the websites can access them? Would this improve performance in any way? Would it result in less memory usage for the JVM? Are there any down-sides?
I haven't been able to find any information related to this situation.
Upsides: a small amount of disk space and RAM is saved. Remember that the only heap space taken belongs to the java.lang.Class instances representing the types you actually load from that JAR file.
Downsides: all applications in the JVM are locked-into using the version of the library that is shared. If you really want all deployed webapps to be identical, then this really is no downside. Deployments can get tricky because you have to maintain a non-standard deployment process (e.g. the webapp is not self-contained) that may be different from container-to-container or between versions of the same container (e.g. Tomcat changed its mind between versions 4 and 5, 5 and 5.5, and 5 and 6 for how to configure "common" and "shared" libraries).
If the web applications are identical, you should ask yourself: should you even be deploying more than one? Instead, you could sniff the URL and use a configuration for each kind of client instead of deploying the applications separately.
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 2 years ago.
Improve this question
So I'm currently reading the "Java A Beginners Guide 7th Edition" book. And the following sentences seemed to me that Applets could be used as virusis. Was this done?
An Applet is a special kind of Java program that is designed to be transmitted over the Internet and automatically executed inside a Java-compatible web browser.
The key feature of applets is that they execute locally...
To me it sounds like it wouldn't be hard to build in a virus into an Applet.
The problem with applets is that they run automatically when you load the page. They're also so complex (compared to html or javascript) it was just to complicated to be able to meaningfully secure them. Run Automatically + Complicated to Secure + Doesn't Update Automatically = impossible to completely secure.
Regular apps are far far more dangerous to your machine than applets were. But, they don't run automatically when you visit a web page.
Desktop apps written in languages (like C or C++) where you manipulate the memory with pointers and don't automatically bounds check arrays, are much harder to write securely. Languages (like Java or C#) that don't have pointers and do automatically bounds check arrays are easier to write secure apps in.
Java includes many safewards to prevent any ill behavior, but time after time, those security features were not enough because of different bugs or design problems.
As standalone apps they are as safe or risky as any other app. Just make sure to download your app from trusted sources.
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 an API in C# .Net for uploading files whose size vary between 10 B - 100 KB. Per second, the system receives around 5 such calls. Now I want to pass this file to a JAVA process (Because it is a producer of Kafka, and we want it to be JVM based, while C# API is legacy). Both are going to reside on the same machine almost always. What is the best way of doing that?
I read about jni4net, IKVM for interacting with Java from C#. Would they be better or should I make it socket based (Web API in Java accepting the files), or should I read from the local filesystem where C# App has uploaded or any other option that I am missing?
In environment with high concurrency, reading from the local file-system might not be good idea.
You could use memory mapped files which java supports with FileChannel.
Depending on operating system, you could also use Named pipes for IPC, here is an article showing how to use pipes between .Net and Java:
http://v01ver-howto.blogspot.com/2010/04/howto-use-named-pipes-to-communicate.html
All options considered, i would go with sockets. They are portable and easy to do and will most likely meet performance requirements you have.
You may also use a message queue. You can either put a binary message, serialize the file or put the location of file on the queue if you are storing the files in the file system.
A solution with sockets and message queues will allow you to have a more distributed architecture i.e. not loading a single machine with too much work.
If you want to actually use the C# API from Java, a bridge is probably the way to go. It'll likely be more efficient than a Web API. Some bridges will also allow you to run the C# and the Java in the same process, which is more efficient still.
In addition to the bridges you mention, you might want to consider JNBridgePro. You can find more information at our website.
Disclosure -- I am affiliated with JNBridge.
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 have a website, consisting of about 20 Java Web applications (Servlet/JSP based webapps), of varying sizes, each handling different areas of the site.
The combined size of all 20 war's is 350mb, however by combining them I anticipate being able to ultimately reduce that and realise combined caching benefits.
Is it best to keep them separate, or merge them into a single Uber webapp war file? (and why)
I'm particularly interested in knowing any technical drawbacks of merging them.
I "vote" to combine them.
Pros
Code sharing: If you combine them, you can share code between them (becase there will be only one).
This does not apply to just your code, it also applies all the external libraries you use which will be the bigger gain I think.
Less memory: Combined will also require less memory (might be very significant) because the external libraries used by multiple apps will only have to be loaded once.
Maintainability: Also if you change something in your code base or database, you only have to change it in one place and re-deploy one app only.
Easier synchronization: If the separate apps do something critical in the database for example, it's harder to synchronize them compared to the case when everything is in one app.
Easier collaboration between different parts/modules of the code. If they are combined, you can simply call methods of other modules. If they are in different web apps, you have to do it in a dirty way like HTTP calls, RMI etc.
Cons
It will be bigger (obviously). If you worry about it being too big, just exclude the libs from the deployment war, place it under the tomcat libs.
The separate apps might use different versions of the same lib. But it's better to sort them out early when it can be done easier and with less work.
Another drawback can be the longer deployment time. Again, "outsourcing" the libs can help making it faster.
There is no drawback in terms of size, memory issues or performance when used in single file as systems are getting faster each day. And as you said running in different apps or same one, the total combined resources consumed will be the same in terms of processing or computation power. Now its a maintenance and administration issues that decides to keep a single or multiple. If you have multiple modules which might changes frequently and independently of one another, its better to have multiple webapps, talking via RMI or WS calls for intercommunication(if required). If all of them are oriented as one unit, where everything changes at once you may go with single app. having multi apps will help to install and update each one easily with respect to change in functionality at module level
deploying multiple applications to Tomcat
http://www.coderanch.com/t/471496/Tomcat/Deploying-multiple-applications-WAR
Hope it helps
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 9 years ago.
Improve this question
Are there any ways in C and C++ to control the memory ram and registers according to our need? Eg. movement of data in ram from one location to other, changing values in registers, etc?
Is it possible in Java???
For memory management you should consider using a Memory Pool. Link.
Though you shouldn't be reinventing the wheel. Use a library instead that provides a clean templated interface to memory pools. Avoid malloc and memcpy as much as possible.
If you wan't to play with the registers you can include assembly code. Link.
I am not sure to understand your question, which is operating system, processor, and compiler specific.
With recent GCC you could do some of it (for instance, reserve registers to avoid them being used). And you could also customize the compiler (e.g. with MELT) to suite more needs. But such a customization means at least weeks of efforts.
You could also make a new backend in GCC (but this means months of work)
And recent standard C++11 library has notably std::allocator and a lot of memory management related stuff.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've recently learned about Tomcat 7's feature to allow multiple versions of the same webapp deployed at the same time:
http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
http://www.javacodegeeks.com/2011/06/zero-downtime-deployment-and-rollback.html
Our sites regularly get 10-20,000 user sessions per day, and quite a lot of them are transactional/stateful type of webapps. Parallel deployment seems perfect for what we want, but I haven't really heard much about people's experiences using it on their servers.
If you use this feature of tomcat 7 in production, have you had any issues with it so far? Have you had to make any changes to your webapps to "play nice" with this Tomcat feature?
I didn't use this feature in production. My first thougths are:
What if you apply database schema changes? You'll have two applications running on same schema with different database handling (for example different JPA entities).
What if you have some scheduled tasks? They'll run paralell. Your application must be ready for this.
What if you apply some very important bugfixes? You'll have good and buggy application running together. They'll together make changes to database until all old sesions expires.
Why do you want your users to see old version of an application if you apply some new features or bugfixes.
Your application must be prepared the same way you prepare it to run on cluster with sticky sessions. It's just the same, but on same Tomcat.
Are you sure your application can be redeployed on Tomcat without well-known perm gen issues? I heard they say it can be done now. I still restart Tomcat with each redeploy.
We didn't have much luck getting this to work consistently in our test environment, so no way we'd consider it for production.
The question is, do you need the ability to do hot upgrades in your environment? Often this is theoretically nice but not needed.