NetBeans issues a low memory message quite frequently - performance

While developing Java EE applications, the NetBeans IDE (currently using 8.0.2 but the issue is not restricted/limited to this version only) issues a low memory message quite frequently.
For example, while modifying and saving some Java classes (especially, JPA entity classes), the memory soon gets over-flooded after repeating this modifying and saving process for merely 10 to 15 entity classes. The IDE issues a low memory message disturbing the whole system severely.
It leaves only one alternative which is to restart the system and I indeed have been wasting more time in restarting the system than actually developing Java EE applications for couple of years :). I have not yet seen anything about this issue over the internet.
The auto-deploy (Deploy on save) option on the IDE is turned off forever. I never use this facility as it causes the heap/PermGen space to get over-flooded quite soon.
This may or may not happen in small toy applications. I am only talking about Java EE applications using a Java EE compliant application server.
I see if there is no way to get around this problem, then this IDE cannot be used in developing real Java EE applications because dealing with this problem basically takes more time than the actual development time and otherwise, the solution may be to lean towards other IDEs like Eclipse, IntelliJ Idea, JDeveloper etc, if they go better.
I am currently using,
GlassFish Server 4.1/Java EE 7
JDK 8u45
NetBeans 8.0.2
Is there a solution somewhere in the world?
NetBeans tends to be slower than other IDEs on Windows but this is far beyond the single term slow.
The picture is taken from a simple test web application (thus not an enterprise application). In enterprise applications, changing a single character in a single entity class is not affordable. One is likely to run into a big problem, if attempted. Fixing those errors shown in the link may take hours or probably the whole day or so.
Not to mention again that I am not talking anything other than large scale applications involving Java EE or other platforms like Spring.
Long story short : Nothing can prevent me from wondering as to how it is affordable to use this IDE in software industries. It is no longer usable in this way (Nothing to abuse. Honestly, I kept patience for almost three years. I am merely wasting time using this IDE).

Related

Java7 vs java5 garbage collection

We are planning to migrate our enterprise application currently running on Java5 stack to Java7 stack. We are having issues with implicit gc calls (mainly major gc) causing system to be unstable for a short time(ranging from 5 mins - 30 mins). After analyzing the gc stats, we found that Compact phase is taking quite long time to complete when compared to Mark and sweep phase. I understand compaction is quite complex and time taking but its impacting the app server which is customer facing and few connections being dropped off during this phase.
Now, my question is as we are migrating to Java7, is there a better garbage collection process compared to Java5?
App servers are provided with decent system resources.
Each app server contains 32 cpu cores
contains 64 gb ram
App server is IBM webpshere server
Operating System - 64 bit IBM AIX
As said earlier, gc is happening because of implicit system calls. No explicit system calls invoking gc.
Now, my question is as we are migrating to Java7, is there a better garbage collection process compared to Java5?
Generally yes, though as #Pushkar, you should really be migrating to Java 8.
With respects to the specifics of your application(s), it sounds like you need to tune / retune the garbage collection on Java 5. If you are periodically experiencing 5 to 30 >>minutes<< of unstability due to GC, there is something rather wrong. The current behavior may be due your application or Websphere (e.g. memory leaks, excessive caching, etc), or it may be due to poor GC tuning.
In short, switching to Java 7 (or 8) might make things better "out of the box", but it is likely that you will need to put in more effort to address the underlying cause of your problems.
Finally, I'd advise the obvious things.
Implement the changes in small steps. Don't upgrade your app, websphere version, java version, etc all at the some time.
Do the upgrades of your servers one at a time. Have a roll-back plan in case you get unacceptable performance.
If possible test it all first ... including performance / load testing.
By default, java 7 uses parallelGC on server class machines. If you are using JDK 7 update 4 or later version, switch to G1 garbage collector which might give you better performance. But as #the8472 suggested,it will be good to know what settings you used in java 5 and now in your current environment.
Java 7 reached end of life around April 2015. Why not migrate to 1.8?
GC performance usually improves with java major releases (and in some cases with minor GCs).
You should take a look difference GC tuning flags, following link may help you
http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html
http://stas-blogspot.blogspot.com/2011/07/most-complete-list-of-xx-options-for.html

Can JavaFX be used as a thin web client?

The question is quite simple:
Can we use JavaFX as a thin client running on a browser while a java server does most of the work?
IE: cretate the UI and it's controllers with JavaFX and have the bussiness/database connection/etc part run on a server?
Even if possible, would it be a complicated turnaround?
Based on the information you've provided, I wouldn't necessarily say that JavaFX is a good fit, but on the other hand I would not worry about the load times. My rationale is: The bad thing about JavaFX is that you have an additional tech requirement for your clients (JVM) and require some form of installation (even if it is just an applet). Those won't be a factor for HTML5. JavaFX has benefits over HTML5 if one of these cases is true:
1) You have complex controls and/or a lot of user interaction with the UI
2) You need your application to be really flashy, e.g. by incorporating animations
3) You have a complex business logic that you would like to execute on the client (e.g. because you had a previous implementation as a rich client)
'Some tables and simple controls' don't really fit here.
The reason why I wouldn't worry too much about the download time is that most users of an enterprise application will be using your app a lot from few different machines, thus caching should deal with that problem (plus an FX app is not going to be that large).
There is an interesting article on the topic to be found here: http://www.oracle.com/technetwork/articles/java/casa-1919152.html . Since it is coming directly from Oracle, you should of course take it with a pinch of salt, but I for one do agree with the general notion. The article also outlines some (subjective) experiences when switching to JavaFX.
If it's an enterprise app, and you already know that your users will have java installed on their clients, javafx is a good solution. If not, the downloading of the javafx jar can be quite a buzz kill the first time an app is run, as it's quite (understandably) large. I'm using it for enterprise apps, and the web start functionality works well.
And don't forget, if you're using jdk 7, there is a javafx packager which will create a single file installer/run-time for your app. I can't provide a lot of detail for that as I haven't bothered with it yet.

IBM RAD 7 and Websphere 6.1 is slow and unresponsive

How can I improve performance when developing locally with Websphere and RAD? I am using one web application of moderate size (1000? classes) and it is impossible to handle the app locally on a Windows box. The Websphere 6.1 configuration uses the default configs. RAD7 is configured to handle a max heap of 1024mb. I thought about increasing the heap of the server. At present, the min and max are 128/300mb.
In terms of unresponsiveness, sometimes it may take minutes to load a page, if the page loads at all. Also, I disabled "Build Automatically" and Publish Automatically. Maybe those should be turned on?
I'm not sure about RAD7 but from my past experience, I'd suggest to give MyEclipse Blue a try.
Since that might not be an option, here are some other usual culprits, you can check:
How much RAM does your machine have? It's good to give WS 1GB of RAM but if your computer only has 1GB of real RAM, it's going to swap itself to death. If your boss won't pay for it, go get some RAM with your own money. 2GB are less than $80 ATM. I suggest to get at least 4GB. Yes, Windows can only use 3.5GB even when 4 are installed but that half GB costs $20 or less. Even thinking about this for more than five minutes will cost more than simply buying it.
Next make sure whether you are using the correct Java GC options. There should be some info about this in the docs. Plus make sure that the process uses the "jvm.dll" from the "server" directory, not the "client" one. "Process Explorer" will help.
Since I'm not using RAD, I'm not 100% sure about "Build Automatically" and "Publish Automatically" but since RAD7 is based on Eclipse, these options will compile code in the background as you type. This will greatly reduce the time between you saving your last change and the moment the app server can start to load the new code.
When all else fails, run websphere in a profiler and look where it spends all the time.
Aaron had great advice.
I would also suggest using JConsole to see what is going on, to help you determine if you need more memory, larger heap size, etc. My experience with running Websphere and RAD locally is that it will be slow, but then I was on an old machine that needed more memory. :)
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
Berlin,
RAD 7 saps your PC! When I was using it to develop Portlets, I followed this optimization guide and it made the IDE significantly quicker to develop Portlets in. Obviously it is aimed at Portlet development but it might help you.
Also following the advice given to the answer to this question will also help.
I definitely agree with Aaron Digulla. You will see a major performance improvement with 4GB RAM installed on your development machine. I developed an Eclipse/RAD plugin with some buddies of mine and we were able to measure how much time we saved by upgrading from 2GB to 4GB.
The plugin is available here: http://lopb.org/
After gathering some hard numbers on how much time we spent waiting for publishing and loading the app on our 2GB development machines, we were able to convince management to upgrade the rest of the developers on the team.
Anyway, you should really consider upgrading to 4GB if you want to run RAD 7 and Websphere 6 on the same development machine. Each one needs -Xms=512m -Xmx=1024m as JVM args to run well, and that means you will swap to disk way too much if you only have 2GB of RAM or less. HTH
Make sure your running was in development mode for your development and testing.
Option is under the server in the console.
Karl
hehe, we had the same problem with RAD6 and Websphere 6.
The way we speeded things up is moved to Eclipse and JBoss.
We developed on Eclipse and JBoss and then first round of testing was on Websphere. We had some issues with the differences but would never had completed the project were it not for out switch (a lot fewer issues than deving on RAD/WAS).
But to help you in the mean time...
Definitely, probably want build automatically and publish automatically off. That way you can make a bunch of changes and then tell RAD to compile and deploy while you go and get coffee.
There is a "run in dev mode" in Websphere (I know there was for 6.0) so track that down and turn it on (it's on the WAS console somewhere)
I found WAS's on stack replacement to work fairly well. I found that at the beginning of the day I'd deploy to WAS and then not have to redeploy at least until lunch time (as I was debugging). I would make changes and the changes would be fed to the server without my having to redeploy.
Chances are, even after running the profiler you'll find there's nothing much that you can do..
Turn off all validations (in RAD), they tend to take forever.
Depending on what you're doing with EE investigate the possibility of deving on another IDE/Server combo, maybe you can do the bulk of your work in there and then deploy from RAD/WAS to do some final testing. If you're using vanilla ejb's or web services this is feasible.
That max heap does sound a bit small to me. The suggestion to fire up JConsole is a good one cause it will tell you how much heap is being used, though I'm not sure if it will work on the IBM vm (RAD's). You might try and turn on the memory usage monitor in RAD, tells you how much memory is being used, that way you can tell if it's hitting the max.
JConsole will not work without specifically enabling it via a JVM command line switch.
Suggestions from Michael Wiles sound reasonable but please update your RAD first to the latest FixPack available.
You can also contact support.

Tricks to speed up Jboss Seam debug cycle

We deploy and debug a Jboss Seam 2.0 EAR app from within eclipse, booting it on Jboss AS 4.2.2. Right now we need to reboot it every time we change the message bundle, pages.xml, components.xml, or the model, which takes up to 45 seconds.
Is it possible to include aforementioned files in hot deployment, and what are the options for boosting boot speeds?
For a frame of reference, we work on Intel quad core 6600's or better, with at least 4GB of ram.
Edit: I'm looking for ways to improve both boot speed (thats the 45 seconds) besides hot deploying message bundle, pages.xml, components.xml etc.
This has been an outstanding issue for Seam for ages now : https://jira.jboss.org/jira/browse/EJBTHREE-1096
It's not a trick - more a method of working - but I have all of my UI code (page handlers etc) as POJOs so that they can be easily hot-deployed. Any more serious business logic I put in SLSB/SFSB and unit test them thoroughly so hopefully I have fewer deploys when testing the application via the UI.
Currently pages.xml can be hot deployed. I've read some solutions for reloading the message bundle but it's never bothered me enough to warrant further investigation.
When you say 'reboot' it sounds like you mean 'shut-down and re-start JBoss'.
You only have to force JBoss to reload the application, by touching the file (for an EAR or WAR archive) or the deployment descriptor (app.ear/META-INF/application.xml or app.war/WEB-INF/web.xml) for an exploded archive.
Reloading the Seam application EAR takes about 15 seconds on my machine, while starting JBoss takes about 30 seconds excluding shut-down but including starting the Seam application.
If you do want to restart JBoss, you can probably make it start faster by removing components you do not need in your development environment, such as JBossHA (high availability and clustering).
Since using JRebel with JBoss I have saved a lot of time.
http://www.zeroturnaround.com/jrebel/
It is not free but imho it is one of the tools that is worth the money and saves a lot of time restarting, redeploying an app after only a small change.
E.g. it reloads messages.properties.
What is it doing during those 45 seconds? If it is loading data from the hard drive then you could invest in a faster one. Non-SSD Hard drives are still a bottleneck these days. Although the time points out to some other issue...
I think it is best for you to open (or look for) an issue at:
https://jira.jboss.org/jira/browse/JBSEAM
(Note: For posting issues you need to login first.)
I've sped up boot time by moving to a war and stripping Jboss to a bare minimum (Since I'm only using seam POJOs and not EJBs).

Asterisk AGI framework for IVR; Adhearsion alternative?

I am trying to get started writing scalable, telecom-grade applications with Asterisk and Ruby. I had originally intended to use the Adhearsion framework for this, but it does not have the required maturity and its documentation is severely lacking. AsteriskRuby seems to be a good alternative, as it's well documented and appears to be written by Vonage.
Does anyone have experience deploying AGI-based IVR applications? What framework, if any, did you use? I'd even consider a non-Ruby one if it's justified. Thanks!
SipX is really the wrong answer. I've written some extremely complicated VoiceXML on SipX 3.10.2 and it's been all for naught since SipX 4 is dropping SipXVXML for an interface that requires IVRs to be compiled JARs. Top that off with Nortel filing bankruptcy, extremely poor documentation on the open-source version, poor compliance with VXML 2.0 (as of 3.10.2) and SIP standards (as of 3.10.2, does not trunk well with ITSPs). I will applaud it for a bangup job doing what it was designed to do, be a PBX. But as an IVR, if I had it to do all over again, I'd do something different. I don't know what for sure, but something different. I'm toying with Trixbox CE now and working on tying it into JVoiceXML or VoiceGlue.
Also, don't read that SipX wiki crap. It compares SipX 3.10 to AsteriskNOW 1 to Trixbox 1. Come on. It's like comparing Mac OS X to Win95! A more realistic comparison would be SipX 4 (due out 1Q 2009) to Asterisk 1.6 and Trixbox 2.6, which would show that they accomplish near identical results except in the arena of scalibility and high-availability; SipX wins at that. But, for maturity and stability, I'd advocate Asterisk.
Also, my real world performance results with SipXVXML:
Dell PowerEdge R200, Xeon Dual Core 3.2GHz, handles 17 calls before jitters.
HP DL380 G4, Dual Xeon HT 3.2 GHz, handles 30 calles before long pauses.
I'll post my findings when I finish evaluating VoiceGlue and JVoiceXML but I think I'm going to end up writing a custom PHP called from AGI since all the tools are native to Asterisk.
You should revisit Adhearsion as v0.8.1 is out, and the documentation has gotten much better quite recently. Have a look here:
http://adhearsion.com
http://docs.adhearsion.com
http://api.adhearsion.com
If you're looking for "telecom-grade" applications, you may want to look into SipXecs instead of asterisk. It's featureful, free, and open source, with commercial support available from Nortel. You can interact with it via a Web Services API in ruby (or any other language).
See the SipXecs wiki for more information. There's a comparison matrix on that site, comparing features with AsteriskNOW and TrixBox.
There really aren't any other frameworks out there. There's of course AGI bindings to every language, but as far as full-fledged frameworks for developing telephony applications, we're just not there yet. At least in the open-source world.
I have asked somewhat related questions here, here, and here. I'm using Microsoft's Speech Server, and I'm very intested to learn about any alternatives that are out there, especially open source ones. You might find some good info in the answers to one of those questions.
I used JAGIServer extensively, even though it's not under development anymore, and it's pretty good and easy to use. It's an interface for FastAGI, which I recommend you use instead of simple AGI.
The new version of this framework is OrderlyCalls which seems to have a lot more features but since I haven't needed them, I haven't tried it.
I guess it all depends on what you want to do with AGI; usually I have a somewhat complex dialplan to gather and validate all user input and then just use AGI to connect to a Java application which will read some variables, do some stuff with it (perform operations, queries, etc etc) and then sets some more variables on the AGI channel and disconnects. At this point, the dialplan continues depending on the result of the variables set by the Java app.
This works really fast because you have a ServerSocket on the Java app, which receives incoming connections from AGI, creates a JAGIClient with the new socket and a new instance of a JAGIProcessor (which you have to write, it's the object that will do all your processing), and then run the JAGIClient inside a thread pool.
Your JAGIProcessor implements the processCall method where it does all the work it needs, interacting with the JAGIClient passed as a parameter, to read and set variables or do whatever stuff the AGI interface allows you to.
So you have a Java app running all the time and it can be a simple J2SE app or an EE app on a container, doesn't matter; once it's running, it will process AGI requests really fast, since no new processes have to be started (in contrast to simple AGI which runs a program for every AGI call).
Smee again. After migrating my client's IVR's over from SipX to Asterisk utilizing PHPAGI, I must say that I haven't encountered any other architecture that anywhere near as simple and capable. I'll be stress testing Trixbox CE 2.8 today on the same hardware I had tested SipX on earlier. But I must say, using PHPAGI for the IVR and the Asterisk CLI for debugging has worked perfectly and allowed me to develop IVR's far faster than any other company out there. I'm working on implementing TTS and ASR today and I'll post my stress test results when I can.
Simple small flexible Asterisk AGI IVR written on PHP
http://freshmeat.net/projects/phpivr
For small and easy applications I use Asterisk::AGI in perl. There are also extensions for the Fast AGI. For bigger applications, like VoIP operator's backends I use something similar to OrderlyCalls written in Java (my own code). OrderlyCalls is great though to start with java fastagi engine and extend it to your needs.

Resources