We have project which utilizes OGNL (3.0.6). When Tomcat server is started in RUN mode, OGNL expression execution takes <1ms. However, when server is in DEBUG mode, same expression executes in around 80 ms, that is 80+ times slower! I have tried everything I could imagine off - disabling OGNL logging (log4j.logger.ognl=FATAL), tweaking DEBUG settings in Eclipse (latest STS 3.3.0) - nothing helps even a bit. What is interesting, this slowdown occured after I have re-installed STS and created brand new workspace. In older STS (same 3.3.0 version) everything was OK, however debugger integration was completely broken (that was the case for re-install). I must mention also, that I'm not alone - my colleague has the same problem with his Eclipse setup.
Please, maybe someone have had similar problems. I would be enormously grateful for any help!
I had a similar problem with Eclipse. Oddly, all I did to fix the problem was clear all breakpoints.
This guy helped me: https://stackoverflow.com/a/1373547
Related
When I go to the "Boot Dashboard" (Update: actually I see similar messages on each Spring view) view I see the message
Could not create the view: org.springframework.ide.eclipse.boot.dash.views.BootDashView
There is an icon to see the error logs beside it, so I deleted them, reopened STS, and I did not see any error.
Any guidance on how to resolve this or further debug it?
More info
After following Martin's advice and opening the Host OSGi Console and typing ss to get the short status and doing diag <id> on a few different things all I was ever able to get was similar to this,
org.springframework.ide.eclipse.boot.dash [962]
No resolution report for the bundle.
Martin mentioned looking for INSTALLED, but all I saw were ACTIVE, RESOLVED, STARTING, and <<LAZY>>. I ran diag on at least one bundle of each state, but got nothing any different than above (of course the names and IDs were different).
I was facing the similar issue with Spring Boot Dash view and using -clean option and restart STS worked for me.
Just faced the same issue upgrading to latest STS 3.8.3 based on Neon.2 (4.6.2). Starting with the -clean option did nothing for me, neither did uninstalling / reinstalling the Groovy Eclipse feature as discussed.
What resolved it for me was switching to a new clean workspace - the boot dashboard then started working again. Oddly, it also works if I now switch back to the old workspace. Before this, the module was showing as LAZY in the Host OSGi console, now it's ACTIVE:
966 ACTIVE org.springframework.ide.eclipse.boot.dash_3.8.3.201612191259-RELEASE
The problem was one of my Groovy Eclipse compiler plugins (it was 1.8, 1.9, 2.0, 2.1, or 2.2, not sure which). After uninstalling it the Boot Dashboard no longer has an error.
Since part of my question was wondering about how to get better insight into the problem (more than checking the error log, which was empty) I will not mark this answer as accepted.
I've been having trouble getting a weblogic server to run in eclipse, which have resulted in me not being able to open eclipse ni my current workspace at all. It is not my first attempt to work with weblogic servers in eclipse, and I do not know why it suddenly decided to stop working. I have had multiple errors, which all seem to be related to an abnormal high memory consumption.
One of my last errors, before eclipse quit on me for good, was an out of memory exception, on PermGenSpace. I set variables to 1024m, but it still complained it wasn't enough. After a lot of restarts, Eclipse suddenly wouldn't open my current workspace. I have tried others, and they work fine, but with my current one, the splash/loading screen disappears after about 10% of the loading bar is complete, and nothing happens at all. Except the fact that eclipse.exe shows up in the running processes tab on Windows task list. It does not show in the running programs list.
My attempts to start weblogic servers had the exact same symptoms. They showed in the process list, but did not respond when I tried to open the console in my browser.
Both eclipse and the weblogic tasks (shown as java.exe) has had over 400.000KB of memory consumption each, which I find very high.
I do not expect anyone to be able to find a complete solution here, but I am absolutely stuck. I cannot access any of my previous error messages. I have no experience debugging an error like this. Does anyone have any idea on how to find the error in a case like this?
My Weblogic version is 10.3.2, which is a company standard for now.
My Eclipse version is:
Eclipse Java EE IDE for Web Developers.
Version: Kepler Service Release 2
Build id: 20140224-0627
Adding the comment as an answer since it provided some help.
Try starting up to a new empty workspace; If you dont get to select workspace at startup use the argument "-data " If you still get issues, look at the log in /.metadata/.log
I've been having problems getting debugging working with this setup for the past year. Supposedly, this is fixed in the latest versions, but I just can't seem to get it to work.
I'm using Mac OSX 10.8.5, Eclipse Keplar, PyDev 3.0.0, and Google App Engine 1.8.8.
I set up a run configuration to point to dev_appserver.py, running my project. That works fine. My python version is 2.7.3, and everything works in normal mode. When I try to run in debug mode, however, the app runs, the output specifically states:
pydev debugger: starting
pydev debugger: google app engine integration enabled
But after 20 seconds, the python process terminates with this error message:
'Launching New_configuration' has encountered a problem.
Timed out after 20.0 seconds while waiting for python script to connect.
Accept timed out
Execution works during those 20 seconds, because I can hit URLs connected to my app and see an effect. Breakpoints do not work, though. Is there something I need to do to get python to 'connect'?
Also - I should note that switching back to using 'old_dev_appserver.py' fixes this problem - debugging works fine when I do this. But, this is not really a solution, because I need to use the latest socket additions in the newer releases.
Thanks for any advice.
temporary solution:
edit the pydev_app_engine_debug_startup.py file:
eclipse/plugins/org.python.pydev_${VERSION}/pysrc/pydev_app_engine_debug_startup.py
change the line that reads:
if ':' not in config.version_id:
to:
if ':' not in config.version_id or config.version_id.startswith('default:'):
Looks like this is fixed in 1.9.0. I also had to make sure to update PyDev to the latest (3.3.3 at the time of this writing).
One more thing to add, and this one really tripped me up (on MacOS) -
In Eclipse, under Run -> Run Configurations, set the Main Module to point to this location:
/usr/local/google_appengine/dev_appserver.py
NOT the symlink:
/usr/local/bin/dev_appserver.py
Well, finally I found the answer. It is a Google's bug.
It has been reported and acknowledged.
see Debug is not working with PyDev again 1.8.8!
Update: Until the bug is fixed I am using PyCharm. The pro version has 30 days trial and works with GAE. It works like, well, a charm. I may even consider switching to it from Elicpse/PyDev
But I am used to JetBrains tools with Android Studio recnetly, and WebStorm and Resharper in the past, so I know to find my way around their IDEs. Your milage may and will vary.
Since the question, a new GAE has been released 1.8.9
Running GAE 1.8.9 with PyDev3.3.3 on Windows8.
This timeout issue still occurred.
When I entered the temporary workaround changes to pydev_app_engine_debug_startup described in the earlier answer, then the browser could not connect to the app.
However, on backing out this change, not only did the 'Launching New_configuration' not appear, but the breakpoints worked.
More info on the Python Tool Support for the App Engine Development Server is here
https://docs.google.com/document/d/1CCSaRiIWCLgbD3OwmuKsRoHHDfBffbROWyVWWL0ZXN4/edit
I searched lot about this topics but can't find a proper solution.
I am using eclipse 3.6 Helios version with operating system fedora15. In my application I am using GWT2.4 for front end development.
Now while I work with debug mode and want to debug at some point at the same time eclipse hangs for 3-4 mins.It resumes after and again start to debug process.
I am using this eclipse from last 3 years with windows but not faced this issue.In fedora I am using it from last 4 months and this problems stated to occur from last one month.
I am not getting what is the issues with eclipse.
Please help me out.
Thanks in advance.
Is this something that happens with different projects/code, or is it the same code that causes freezes? I've had issues where threads have started in the background and caused problems.
You say "(...) hangs for 3-4 mins.It resumes after and again start to debug process.", what do you mean? Does it continue to debug and move to the next line, or is there a crash and it restarts?
How long has it been since you changed workspace? I've found this, rather than the Eclipse installation, to be an issue over time. Create a new workspace folder, export all your projects and preferences and start fresh.
You are using GWT 2.4 and I think you might be working with UI.xml too... There is a tag in each ui.xml at the top like
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
Which means eclipse is going to get that xhtml.ent file each time and there is a issue in GWT eclipse plugin have a look to below link
http://code.google.com/p/google-web-toolkit/issues/detail?id=5265
There is one comment which says
For me, removing
SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent"
and saving the document,
solves the problem..
maybe it is needed for something, so better you copy that locally somewhere, and link that.
Try it out and let me know.
I had experienced the exact same problem on a less-powerful notebook I had to use.
Try one of the following
Download the latest Eclipse version (It needs, just as helios, a lot of RAM and CPU because it's based on a new "architekture", in contrast to, for instance, galileo)
Make sure you are using the latest JDK and JRE
Download Eclipse Galileo, which does require pretty less resources and goes still very very fine with most projects!
It sounds like you are experiencing the features of the latest Eclipse arch. In the latest versions of Eclipse I have noticed that the more plugins and add-ons you have installed, the slower the environment runs. There are a lot of similar posts regarding performance on the new platform
I have removed all but the plugins I am using and never install anything not needed into the Eclipse environment.
I "may" have experience this. Not sure. Suddenly started working again. I was getting a hang every time I would try to debug an app, in the part of the code (inside GWT) that creates a "table" element. Could be that there is something that just takes a while and you just have to "wait it out" the when it happens. Go get a cup of coffee, type thing. anyway I HAD stepped deep into the GWT code, plenty so I'm convinced it IS a GWT issue of some kind.
I was thinking it was some infinite recursion possibly in the logging system (like logger code accidentally trying to log itself, and going into loop?). Also there's a 50/50 chance that it was simply clicking on 'run' instead of 'debug' made it start working again. So at least try that if you have problems. My gut instinct and 30yrs programming under my belt tells me it's logger related. I can rule out "slow computers" because I never had this happen until I got a new machien which is Dell XPS, Core i7, 8 GB ram, and massive disk. So I wouldn't blame hardware, or Eclipse bloat.
I recently attempted to set new breakpoints in eclipse to debug service side code in GWT. For some reason eclipse refused to see the breakpoints or the new code changes I had made. In the debugger it would open up what appeared to be an ear file from somewhere. Even though I had deleted the old ears, compiled and redeployed the new ear files. We are using GWT 2.1, JBoss 4.3, java 1.6 and Eclipse Helios. Finally, when I created a new environment with the code from scratch it started working. Any ideas as to what was holding on to the old code? BTW, I had rebooted my machine and restarted eclipse, but it also didn't make any difference.
Thanks,
James
Current state of debugging GWT apps is ... well not really good. Sometimes it's incredibly slow (development mode), sometimes lot of rubbish stays at webserver.
This might not solve your problem directly, but here are some advices from me:
Writing new client code (/client) at GWT means refreshing browser
Writing new server code means "Reloading web server". You have little yellow "refresh" button in Eclipse in "Development Mode" tab. This should reflect all the changes done at server side.
Embedded Jetty works usually well with GWT debugging. If you are not doing something jboss-server-specific, it should also work fine at production server. Just make sure your unit tests pass ;-)
You can ofcourse debug GWT application on external server, see this section of documentation (I guess you do on JBoss)
Be sure to remove all old files when reloading web server. It happened to me, that sometimes there were some weird old mixed up files (I was using Tomcat though). So you might want to write own clean script.
You must be absolutely sure that your serever code even launched! Use lot of GWT.log() at client side, that will ensure you in this. Don't worry, GWT.log are ommitted in production mode.
Be sure to inspect client-side page, it sometimes help to find out that your server code didn't manage to launch.
Log every public void onFailure(final Throwable caught) { of your AsyncCallbacks to get more info.
Don't use Google Chrome in development mode. It's MUCH slower than Firefox.
Otherwise, if you're using most recent version of your application, Eclipse must stop at breakpoint correctly.
I think JBoss was somehow caching things in it's temporary files and then I had forgotten about adding source in. This may be a JBoss thing as I don't recall seeing it with other application servers before.
So after I cleared out the cache, what got me thinking about the source was the fact that eclipse would stop on the breakpoints in the debugger that I had just set, but I couldn't see the source files.
Prior to this I was apparently hitting the breakpoints in the cached files and I couldn't alter them by setting new breakpoints. That was the root cause of the issue. Then by adding in the source from the ear, I got the debugger in sync with the code and it started working fine.