java.util.concurrent.TimeoutException after sometime of usage when using content assist #136
Comments
|
It looks like the language server for spring boot is not responding in time, which then causes the completion processor to timeout and go crazy. To track this down, it would be very interesting what the language server process is doing while this happens. Can you look up the process ID (you will see that process showing up in the list when you do a You could also enable the language server logging in the preferences ( |
|
(oh, and btw, I moved this issue over to the sts4 project, which is the one for the STS4 efforts) |
|
I didn't face this issue anymore after I opened this issue oddly. But that could be because I switched back to Java8. I will now change it back to Java11 to track this down. I will post the logs if I encounter it again.
Oh. must've missed that, sorry about that. |
|
No problems at all and glad to hear that this is working again for you. So lets close this issue here for now, but please add the results from your Java11 experiences here, so that we can re-open this in case. |
|
The problem just reappeared in a Java8 environment. This is a thread dump I took via I'm not sure if this is what you needed and since the problem will go away when I need to restart the IDE to enable the language server logs I can't do that right now. [1]: |
|
Thanks for that. It is a useful piece of information. Probably not enough yet to solve the whole puzzle, but at least a piece of the puzzle :-) It shows that Eclipse process is trying to send classpath information to the spring-boot language server. My guess is that this is stuck for some reason. What reason? I don't know. We might know more if we can get two additional dump/logs.
So if it should happen again, could you try collecting this info (actually the number 2 is more important than the server logs, though both could provide valuable clues). For the server process, use jps to identify it. It should look something like this: |
I've turned on the logs now, and will update this thread if I get something.
I actually thought I did exactly that? I typed in |
Actually... yes, you are right. So I must correct what I said before. The trace is not showing being stuck when sending classpath information, but rather being stuck when registering for classpath information. Either way, I guess the picture only shows half of what we want to see. The language server is trying to connect back to Eclipse to ask/subscribe for classpath change events. If that is 'stuck' it probably means the 'other end' is not responding. So we have to try to determine why. The other end in this case is Eclipse. So a jps of the Eclipse process might be helpful, as well as the contents from the Eclipse error log. I think your first paste was a fragment from the stuck Eclipse. But it seems to have been 'chopped'. I suspect what is going on is some kind of a 'deadlock' situation where they are both kind of stuck waiting for eachother. Sorry for the confusion. With two processes I got a little confused and junped to the wrong conclusion. And sorry for asking more of you, you have been very accomodating so far. But... if it happens again, please get dumps from both stuck processes. And hopefully that will allow us to see exactly how things are getting 'deadlocked' waiting for eachother. |
|
Also, if you collect the dumps, please don't try to cut out the 'interesting pieces'. I understand you might think this is helpful, and appreciate that intention. But it is better to have some extra but useless info than to accidentally leave out some pieces that could help us build a more complete picture of what is going on. |
|
Afterthought. Even if we can't get more dumps perhaps there is enough information to attempt to 'unblock' this deadlock. This fragment of the last dump: is almost certainly part of the 'deadlock cycle'. So even without knowing the cause / shape of the whole cycle, if we somehow make this more asynchronous so it doesn't block, it will probably break the cycle. |
|
@jonashungershausen I'm really not sure this is actually a real fix as don't still fully understand what is happening. But seeing as these are good changes to make regardless I went ahead with them. It would be great if you could try using the latest nightly build, which includes the fix, and see if it helps alleviate the problem you are experiencing. You can download a nightly snapshot from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html |
No problem at all! I'm happy to help and as I'm using the STS on a daily basis I'm very interested in it working properly ;) (Which it does, otherwise).
I didn't and I will not in the future, I don't really have a clue about what I'm looking at with these dumps so I will just let you decide whats important and what's not. I will try the new build today or tomorrow and report back. The problem with this error is obviously that it's not really regularly happening and thus I can't say if it's fixed or not. But I will report any finding I get back here! Also thank you very much for your work here. |
Yes, that is the problem :-) Neither can I. Just use it for a bit and report problems if you see any. If no problems... we will assume its fixed :-) If you do see prioblems we can try to fix them. |
|
I came back home after I left the STS open on my suspended laptop for over 24 Hours and I got the same problem again. I figured I take the opportunity to dump the Eclipse & the langugage server thread while it was hanging but this is still with Also there is no output in the language server console log. |
|
Haven't gotten any reports about problems with the snapshot builds made after my supposed fix. So will assume this is fixed for now. |
|
had the same issue, update to 4.0.2 fixed it for me. |
|
I think i have some similar problem with Mint 19.1 mate with java jdk 11 and STS 4.2.0_RELEASE: this is my log file (xsession-errors): (Spring Tool Suite 4:10666): Gtk-CRITICAL **: 17:59:46.581: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (Spring Tool Suite 4:10666): Gtk-CRITICAL **: 17:59:48.165: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (Spring Tool Suite 4:10666): Gtk-CRITICAL **: 17:59:48.239: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (Spring Tool Suite 4:10666): Gtk-CRITICAL **: 17:59:48.243: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (Spring Tool Suite 4:10666): Gtk-CRITICAL **: 17:59:51.980: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar I don't know how to fix it. |
|
@jonas-jonas A few fixes around similar errors have gone in recently in both STS and lsp4e. Could you please try with recent STS 4 snapshot/nightly build and see if it helps? You can download one here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html If you still experience problems in the snapshot, please raise a new issue. Although the error looks similar (timeout exception) the stacktrace itself actually does not. So I would prefer to treat this as a separate bug rather than add-on more clutter to an old/closed and already very busy issue ticket. |
|
Thanks for the headsup @kdvolder. Though I didn't have many problems related to this issue in the last few weeks. The issue has been 'hijaked' by @casper5822 (his comment). However I will download and use the nighly to test it out (currently I'm getting an 'access denied' when I try to download from the url you linked) and report back if I find anything. |
|
@jonas-jonas Sorry, yes, my comment was actually directed at @casper5822. Not sure how I mixed that up. I wanted to suggest @casper5822 try the nightly build and see if it helps with his problem and, if not, open a new issue. Of course that doesn't mean it isn't useful for you to try as well :-).
I just tried it and looks to be working. Maybe try again? If it's still a problem now try clearing your browser cache. |
|
Hi kdvolder. |
|
@casper5822 Great news! Thanks for letting us know. |
Hi,
sometimes after some usage of the Eclipse Spring Tools version, I'm getting UI freezes when trying to use content-assist (Ctrl+Space). There is also a stacktrace in my
journalctl -f[1].I'm not sure why it happens though. I always just use the IDE as normal and after some time of usage without problems, I'm getting this problem. A restart of the IDE fixes the problem.
Specs:
I'm happy to provide additional info if needed.
[1]:
The text was updated successfully, but these errors were encountered: