I've read here that attaching .jar files to domino agents causes a memory leak and the solution is to add them to jvm/lib/ext and restart the jvm. However I understand that putting them in the /ext folder can cause some security issues (see comments).
Is the memory leak problem still the case in Domino 12.0?
Would using the OpenNTF Domino API solve this issue?
Are there any long-term memory leak issues in just using .jars in the /ext folder?
Thanks all.
Yes, the memory leak problem is still an issue in Domino 12.
BUT: There's a workaround. Set the following notes.ini to cache the agentloader objects and reuse them:
EnableJavaAgentCache=2
From SPR # BHUY8PRMKK:
“The Product Development Team had developed a possible fix that
mitigates the issue but the fix was of medium risk and it was decided
not to submit the fix. As an alternative they have come up with a
workaround. Set the following notes.ini, this will cache the
agentloader objects and reuse them.“
Source: https://www.eknori.de/2021-03-20/java-agents-with-imported-jar-files/
Related
Pretty frustrating, yet hopefully small problem I'm running into.
I've just downloaded and installed NetLogo 5.0.5 for my windows 8 machine, standard install in to Program Files (x86). When I try to run the .exe I get this error message
The JVM could not be started. The maximum heap size (-Xmx) me be too large or an antivirus or firewall tool could block the execution.
I've been through the NetLogo User guide recommended protocols of accessing the .vmoptions file and changing
-Xmx1024m
to
-Xmx512m
in order to solve the max heap size issue, but I'm still receiving the same error message. I'm assuming therefore that it has something to do with my antivirus or firewall. I've recently switched my antivirus from Norton Internet Security to Bitdefender, and this is when the problem started to appear.
Any suggestions?
Much thanks!
Googling "BitDefender Java" gives a bunch of results indicating that BitDefender is aggressive about blocking Java-based software (such as NetLogo). The most useful-seeming link I see is:
http://forum.bitdefender.com/index.php?showtopic=28551
but you might try the search yourself and see what you turn up.
So it seems this primarily a question about BitDefender, rather than primarily a question about NetLogo. If you need help configuring BitDefender, perhaps someone here can help you. Or, you might have better luck at http://forum.bitdefender.com or http://superuser.com than here; Stack Overflow is primarily for programming questions.
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
As a general question, are there any reasons that setting the Staging Mode to "nostage" instead of "stage" could cause performance hits? I was originally using "stage" mode, but after some issues with redeployments, I decided to try "nostage". This caused the application to perform almost two times slower. After switching the staging mode back to "stage" in the console, the slowdown was gone.
I was under the impression that the staging mode only "determines how deployment files are made available to target servers" (from the Oracle documentation page), and would not affect the runtime. Is this normal behaviour? I'm having trouble finding information on any links between staging mode and runtime performance.
Stage or nostage should not impact runtime performance. It is hard for me to find out what might cause your performance slowdown without further information, but one thing I can suggest is to switch back to staging mode if that seems to give you the better performance before you figure out the root cause. As to the redeployment issue you mentioned in your answer, you did not provide any details, but I guess it might be related to WLS still picking up the old files instead of new files. You can do some extra steps during your deployment to fix that
Undeploy your app
Shutdown the whole domain
Delete the tmp/stage/cache directories under each managed servers
Start the servers in the domains
Do a new deployment.
Of course, it sounds cumbersome, but you can automate all these into your deployment scripts.
I've read several stablity issues with modmono under high load. The root of the problem is GC and the solution is restarting modmono every n hours, and n should be decreased based on error frequency.
I'm planning to develop a heavy load site with mono (I've .net experience and a little java), and I've fears based on this issues like session interruption, http errors ...
At this starting stage of the project, should I switch to Java/tomcat or trust to mod_mono ?
Regards
Depending on how long developing your site (http://www.mono-project.com/Compacting_GC) might be ready for production. While, googleing found some complaints about stability, many were from 2006. Push comes to shove, if mono/mod_mono fail to live up to stability, you could always deploy from windows/iss.
It's a bit of a calculated risk at this point, but if you run into any issues, I'm sure the mod_mono mailing list would help sort out any issues.
We have developed a Groovy application. Under development for starting it we use the following command line
C:\myapp>mvn grails:run-app
Without sending any request to the server one can see how the memory used by the java process in increasing and increasing. When it starts at about 100M are allocated and a couple of hours later -without doind anything- the memory goes up to 300M.
When I start the application directly
C:\myapp> grails run-app
the memory consume is somehow different, without sending any request it is somehow stabilized at 110M. Sometimes goes up, sometimes comes down.
Although 300M is not critical I would like to know if this is a memory leak or not.
Is anybody having similar behaviours?
Thanks!
This could be a memory leak in Maven, but more likely a leak in the grails:run-app command. I would suggest posting this on the Grails development mailing list.
Why does this concern you? You should only be using these commands for development, not production as you'd be deploying a war file in production. If you're simply concerned, the Grails development mailing list is definitely the place for something like this.
I doubt there's a memory leak here.
It's perfectly normal for the JVM to wait on doing a full GC until it has to. That means if you allocate more memory, your java/groovy process will happily consume it.
Most likely you have different default memory settings for Maven vs Grails. I'm not sure exactly how these properties are set in windows, but they look something like:
GRAILS_OPTS="-Xms100m -Xmx110m"
MAVEN_OPTS="-Xms100m -Xmx300m"