Restart (r) in dev mode kills the debugging session

[andre-doherty]

hello,

I wanted to report that behavior :

When debugging an application (so when in dev mode), if "r" is hit from the terminal, then the debugging session is gone.
The liberty server will allocate a new debugging port and so the existing configuration will have to be modified to be able to hook again with the debugger.

To be noted as well :

• there are some leftover configurations for previous debugging session in the debug view (see below)
• restart is missing from the liberty dashboard

Regards,
André

[scottkurz]

André, thank you for your feedback in reporting this issue.

Like you noted, there are actually a few separate issues:

• First, we do have an issue open to add a Restart operation.
• We do have another issue for the way the Debug "sessions" don't get cleaned up.
• Besides that there is the fact that, having typed the '(r)', you end up with an unusable Debug config.

In general though we haven't thought of the lack of a Restart operation as too much of a priority, since there is the alternative of simply doing a Stop, waiting, and then doing a new Start (Run/Debug etc.).

In our view, the time spent in restarting dev mode mostly consists of the time spent starting the server and the app within the server. (This is especially true since there were some enhancements in Liberty runtime v23.0.0.8 such that the install feature step happens much more quickly when the features are already installed). By that line of thinking, there's not much extra overhead to restart dev mode, vs. trying to just restart the Liberty server within dev mode (the latter is what you'd do by typing the '(r)' which you originally noted).

Of course, one operation (restart) would always be more convenient than two (stop/start). But besides that, I'm curious if you basically agree with that assessment, in your experience, or if you have any further thoughts here.

But beyond the first two issues I listed at the start of this comment, the third deserves consideration on its own.

Another data point here is the fact that the earlier 23.0.9 release our support was a little smoother in this type of use case. Previously, when we were still generating a Remote Java App-typed Debug config, you could simply "re-launch" and the debugger config would connect to the newly (restarted) Liberty server. Now that in 23.0.12, where we've streamlined Debug to use a single Liberty Tools-typed Debug config, there's no way to only "relaunch" the debug without relaunching the whole underlying dev mode as well.. and so this isn't an option. (I'm actually not sure exactly how you ended up with a separate port during your restart but perhaps you did something along these lines.)

It would be nice if there was something like a "Reconnect" option. I.e. don't re-launch dev mode, just take the Debugger portion and reconnect and launch a new Debugger session without a whole new Liberty Tools launch. I'm not sure how to go about this though, but we can keep this issue open to consider.

Let me wrap up by saying there is a lot there, and I don't expect you to respond to all that, but please do share a bit about your use case if you can, as requested. Thanks again for your feedback on the tooling.

[andre-doherty]

Hello Scott,

First let me correct my mistake, you're totally right, the port number now remains the same after a restart.
That was not the case with the 23.0.9 i believe and to be able to reconnect i had to change the port in the configuration (which as you point is now impossible).
Sorry for that imprecision.

As the general user experience on the reconnect to debugging session, i was thinking that maybe a solution would be to drive all the commands through the liberty dashboard (as yes, restart devmode or restart liberty within dev mode is very similar).
Unless i am mistaken, there are roughly three commands that can be triggered from the console : g, r, and to run the tests.
Running the tests is already covered, so maybe restart could be covered as well as generate.
In that perspective, users could interact from only one place, the liberty dashboard, which might be a little more consistent UX.
The output also might in that case get back to the more usual and standard console (which has the ability to interpret URL etc).

What do you think about that?
André

[scottkurz]

First let me correct my mistake, you're totally right, the port number now remains the same after a restart. That was not the case with the 23.0.9 i believe and to be able to reconnect i had to change the port in the configuration (which as you point is now impossible). Sorry for that imprecision.

OK, thanks for clarifying. No need to apologize.

As the general user experience on the reconnect to debugging session, i was thinking that maybe a solution would be to drive all the commands through the liberty dashboard (as yes, restart devmode or restart liberty within dev mode is very similar). Unless i am mistaken, there are roughly three commands that can be triggered from the console : g, r, and to run the tests. Running the tests is already covered, so maybe restart could be covered as well as generate. In that perspective, users could interact from only one place, the liberty dashboard, which might be a little more consistent UX.

I appreciate your suggestion, but after thinking about it I feel it's better to think of the dev mode keyboard commands as a bit distinct from the Liberty Dashboard operations. E.g. consider restart. If we were to try to simply expose the existing keyboard commands through the dashboard we would have some kind of restart that would restart just the server, within dev mode. I think though that it'd be actually more useful to have a dashboard operation to restart dev mode (mvn) itself. Even if I'm wrong, I think it shows having 1-1 similar commands isn't obviously the best.

You mention "consistency". I think perhaps it is just a bit unusual to interact via the Terminal at the same time as interacting with the dashboard. One thing I don't like about Terminal is that once it gets control the Eclipse shortcuts aren't usable (not to mention Ctrl+C doesn't do copy). Not sure there's an easy answer here just appreciating the point here.

The output also might in that case get back to the more usual and standard console (which has the ability to interpret URL etc).

I just want to make sure you're aware that you can, in the terminal view, click on URLs to open in a browser. You just have to press the Ctrl key (on Windows) as you're pointing to the URL, and then it turns into a clickable link:

Question on the impact

So let me ask, having had this discussion, how big of an impact does the lack of a restart operation feel like, to you? Does it seem OK to do stop then start again, yourself, as two operations? Or does that seem mildly annoying? I'm guessing it's probably not too big a deal to work around but does it feel at all consequential here? Thanks again for your feedback.

[andre-doherty]

Hello @scottkurz,

Thank you for the tip, it also works on mac (Command + click).

Well the most annoying is the lack of capability to reconnect to the debugger.
So that as it disconnect everytime the server restarts, i have to perform a stop and a start in the dashboard to recover debugging capabilities. That would be easier of course if that was possible.
Full restart in dev or run would anyway be really appreciated.

There is also one case i should probably mention, when the hot swapping fails, eclipse will popup and ask for a terminate, restart, ignore. Of course in that case also the restart will have to be done twice to recover debugger use.

During one day of work those situations tend to reproduce quite a lot which is why i am arguing :)

[scottkurz]

Taking another look at this and the draft PR 508.

This PR is a nice improvement on the HCR failure path.

I can see it still leaves e.g. the path in which dev mode restarts the server upon a bootstrap.properties update.

Let's think about that more.

[awisniew90]

Hi @andre-doherty - just wanted to let you know that we are targeting 24.0.12 for this support. Hammering out the final details after your latest feedback (thank you!), particularly with handling debugger restart when a "disconnect" is explicitly selected on the debug target.