Why is VPN connection on Mac OS X causing Eclipse to lockup during 'edit launch config' operation? - eclipse

I have been using Eclipse on Mac OS X from home over a VPN to develop GWT and perl code in a local workspace for my employer. Recently a repeatable and severe lockup began occurring whenever I tried to edit Debug (or Run) launch configurations. I got the spinning beachball of death (SBOD) and, if I waited long enough (10-15 minutes) it would eventually stop and I could at least close the dialog.
I tried numerous things until a coworker suggested trying it with VPN turned off. To my surprise (and somewhat delight) it began behaving normally in the above scenario. I have been using Eclipse in this manner for about a year with no problems so naturally I am racking my brain trying to think of recent changes to VPN and/or to my split tunnel script (euphemistically called 'multihome') that could account for this abnormal behavior. This lockup occurs with or without the split tunnel.
I should also point out that the "initializing Java tooling" progress status ALWAYS occurs when starting eclipse and takes about a minute to complete with VPN connection. Normal (<2 seconds) without.
So, I'm starting to learn how to use wireshark and possibly will look into using packetlogger as well in an attempt to find out more about this strange issue.
Anyone have a clue as to what might be causing this?

This is a hard one to answer. Short answer is "I don't know".
However, I did find out that, due to the recently updated JVM, done as part of the Mac OS X update, Eclipse IDE lost its ability to find the src.jar file for the JRE. As a result, it appears that Eclipse, in various places in the code, searched for this file and when not found attempted to find it via the network. When VPN was turned on, perhaps this exacerbated the problem.
This was solved by fixing the Installed JRE configuration of Eclipse (see JDK on OSX 10.7 Lion).

Related

Netbeans 8.0.2 `scan for external changes` suspended, and no auto popup

I am using NetBeans as my IDE. After working a few hours, I got the following problems
1. It got stuck with scan for external changes suspended
2. and after this came, the auto-load also got fails. It shows please wait... only.
Due to this I am planning to change my IDE. Is there any way to overcome this? I thought it was due to the issue with my slow computer. I just formatted and upgraded it. Then also it shows the same issue.
My NetNeans is the small package with PHP and HTML only.
3. It also cause high CPU usage sometimes
My operating system is Windows 8.1 with 4 GB memory and i3 processor
You should close your old projects that you are not working. You clears your netbeans cache as well.
You can get help about clear netbeans cache from here

where can I report/get response on eclipse crashes caused by 14.02-14.04 upgrade?

Yes, I know. I got no rep on this site. But I have to ask this.
I upgraded my laptop, my main dev machine, from 14.02 LTS to 14.04 LTS and the plugins I use with eclipse (3.7) completely broke. I use WOLips (https://github.com/wocommunity/wolips) with eclipse. WOLips is for working with WebObjects applications.
I was getting two crashes. One would occur when editing a java file, when auto-suggest kicked in. I fixed this by adding "-Dorg.eclipse.swt.browser.DefaultType=mozilla" to the end of my eclipse.ini. I have no idea how I found that. It took a lot of random searching.
Now, I get an exception whenever I open a WOComponent:
Unhandled event loop exception
No more handles [Could not detect registered XULRunner to use]
Trying to define a XULRunnerPath just gives me even stranger errors.
I can file a bug with eclipse (which I did). I tried eclipse 4.2 and 4.4 and got other complicated integration issues. I can file a bug with mozilla (though I was not aware that they were involved). I can install a copy of xulrunner (outside of my copy of Firefox) and point to that (which I did). I can file a bug with ubuntu launchpad (which I did). None of these get you very much response.
So, I was going from one LTS to another LTS. 14.04 - 14.02 = 0.02. Not a huge deal, yes? Should I have expected problems? How can I file a bug with the people involved in just this upgrade and not the other twelve systems that this touches upon?
I had Apple laptops for a long time. I do not expect that amount of hand-holding. But I do wish someone would throw me a bone.
I can get work done if I go buy another hard disk, install 12.04 onto it and copy all of my data back. Is this really necessary? You know, I am willing to help integration testing of these releases. But the systems for finding the right place to put my oar in the water seem fairly impenetrable. Any suggestions? I do not mind working for a solution. If there is a solution.
Ray,
Did you try Eclipse 4.4 and use the instructions on the wiki for compiling the new WOLips? the Eclipse 4.4 is acting just fine for me (but I'm on a Mac sorry :( )

Unable to stop Grails app from Eclipse (on Windows)

I'm setting up a Grails development environment using Eclipse (on Windows) and I've noticed that after the sample app starts running (not debugging, just running), no matter what I do I can't terminate the running app. I've tried the obvious red square (on the console window and on the debug view). I've also tried running "stop-app" from the grails command window. But the app still continues to run. Is this a known issue? Is there a fix for it?
Not sure if this matter, but the only thing that I did in Eclipse other than installing the Groovy/Grails plugin is to also install support for the Groovy 2.1 compiler.
Everything in 2.3 is forked by default, so there's one JVM that you start, and it has the Ant jars and other stuff that's needed to start Grails, but that pollutes the JVM unnecessarily. The 2nd JVM that the first process starts is lighter-weight with only the jars that the app depends on, i.e. the Grails, Spring, Hibernate, etc. jars. But this is a tricky thing to do, and unfortunately Windows doesn't get much testing during development because the Grails developers get to choose which OS to use (unlike a lot of Grails users who often have Windows forced on them) and Windows is not chosen - it's all Mac and Linux.
I haven't followed this closely because it was quite buggy early on and I'm now in the habit of just disabling forking any time I create an app. There's probably a better approach, but I delete the grails.project.fork property from BuildConfig.groovy. You can comment it out, or disable forking for a particular launch type ("run", "test", etc.) but deleting the whole block disables it across the board and I find that things work well after that.

RAD project build issue: The project was not built due to "Could not delete

I am using RAD 7.5 on a Windows XP m/c. Whenever I try to do a clean up/build the project, I get a message saying
The project was not built due to "Could not delete 'D:\Documents and Settings\User\My Documents\project\exe\EXE\WebContent\WEB-INF\classes\BusinessRules.properties'.". Fix the problem, then try refreshing this project and building it since it may be inconsistent
To overcome this problem, I need to stop the server, manually delete this file & then build & restart the server. Any idea why I am facing this issue?
I've experienced the issue in RAD 8.0, but not nearly as consistently as you. A second build attempt nearly always resolves the problem for me.
Although there are a number of references to this issue on the Eclipse bug tracking site, none of the bugs I've read have a definitive answer on the cause. There is some speculation that it may be due to a file handle leak. The problem appears to have begun around Eclipse version 3.6.1. I'm not sure exactly which Eclipse version RAD 7.5 is based on, but I believe it is 3.6.1 or later.
Does the issue only occur when the application is deployed and the server is running? I was wondering if you'd gotten the same results with the server shut down.
Unfortunately, the only concrete suggestions I can offer are to try refreshing the project frequently, and perhaps creating a new workspace -- its a bit of a hack, but a creating a fresh workspace has fixed a few really odd RAD issues I've encountered.
Here are a couple of the bug reports from the Eclipse bug tracking site:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=309235
https://bugs.eclipse.org/bugs/show_bug.cgi?id=332607

Anyone have issues with Eclipse over Remote Desktop Connection?

I have a very strange issue that I'm hoping someone can help me with. I have various installations of Eclipse on my development machine at work. The one I primarily use is Weblogic WorkSpace Studio 10.2. This installation, along with a few Pulse installations I have set up works fine when I'm logged into my computer physically.
However, when I try to log into the computer using Microsoft's Remote Desktop Connection utility I get an error stating: "Could not create Java virtual machine." and then I get the lovely Eclipse error box which I personally can gather almost nothing from.
Even if you don't have the solution, any help would be greatly appreciated.
Justin
What ended up working for me was the memory settings for the JVM. Apparently the remote desktop connection, or some other setting in Windows, blocks off a fairly large amount of space. By reducing the heap size allocation for the JVM during Eclipse and server start-up I was able to get this working. As a side note, I had PLENTY of space that windows could have used, so I don't think blankly adding more memory would necessarily solve the issue. If you find another solution, please let me know.
• We came across an issue when user RDC’s to a remote system where the OS is Windows 10 and has a running Eclipse instance, the Eclipse instance terminates
• Eclipse is one of the IDE’s for Java
• The issue is because of Windows 10 Exploit protection
• Pre-requisite: You will need Administrative permissions for executing the below
• Navigate to Settings -> Update & Security -> Windows Security -> App & Browser Control -> Exploit Protection Settings
• Add the program to exclude as below
P.s. As of Window 10 1909 MS security advisory mentions we can disable some exploit protections by default.
Perhaps it is permission related. take a look at similar issue that symantec has:
http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/8ea1593f1d1fcee68025759a003d8403?OpenDocument
Try to see if you have same patches installed that causes the security issue. Also refer to application log to see if there is a more specific error. Good luck :)
I think issue happens due to Windows, not Eclipse nor JVM. There is still open Bug report on the Eclipse side and one of the comments state that Microsoft is working on the issue.
I have tried Windows Remote Desktop-ing into my dev machine at work (which had only one version of eclipse installed on it). I had no troubles.
Is it possible that your problems stem from multiple versions of eclipse running at the same time?
Also, have you tried a fresh install of eclipse on your dev machine?
If the above two suggestions don't work, then the only thing that I can think of is what Mohammad said: you might need to check your permissions.
I would check the system log if I were you: Start > run > eventvwr
The first thing to look at is the .log file which is in your eclipse's metadata folder (found in your workspace at $WORKSPACE_ROOT/.metadata/.log). If you post the stack trace that it generates upon initialization, we can give a definitive answer.
I am now experiencing this in Eclipse (the Oxygen release and Java 1.8.0_181). I previously had the same problem with another Java-based program (Oxygen XML/XSL editor - the product name is coincidentally the same as the Eclipse version). Last year the Oxygen support team answered that it may be a known problem in Java.
Even without seeing a crash report, considering your sequence of
events, this seems like a known common cause of crash for the Java
runtime. Keeping Oxygen/Java running for a long time, until the screen
or video card enters sleep then connecting/disconnecting
screens/projectors or connecting/disconnecting RDP can trigger a crash
in the Java runtime. We keep updating the Java runtime (JRE) with each
new version of Oxygen, but so far the issue has not been resolved in
newer versions of the JRE.
e.g. Java VM logged issue:
https://bugs.openjdk.java.net/browse/JDK-8153389