[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [che-dev] Debugging in Che 7
|
Second option, remote debugging on the applications container is the
intention of the workspace design.
It is the only option that should be used.
Everything else is a bug.
Thanks,
Gorkem
On 2 Aug 2019, at 20:36, Angel Misevski wrote:
Hey all,
I'd like to open a discussion on how debugging in Che works, and how
we ideally want it to work in general. As I've been working through
our current devfiles for the 7.0.0 release, I've been figuring out
debugging setups and found some configuration to be confusing from the
perspective of a non-Che developer.
I've attached a diagram of the three modes of debugging currently used
in Che + Theia:
- The first section represents the only local debugging possible:
running the application being developed directly in the Theia
container. This is typically impossible, due to either missing
dependences or the tight memory limit on Theia. As a result, most
debugging on Che is *remote*. I've opened an issue [1] to try and
prevent Theia from offering this option by default as it can be
misleading.
- The second section shows what I believe to be the ideal setup.
Remote debugging works by connecting to the running application in the
normally configured development container. This seems best, as the
container should have enough memory allocated and normal user tasks
operate there. As an example, this is how we currently support Java
debugging. This mode is also (when it works) the easiest to configure,
as the user is expected to interact with the main container only.
- The third section shows how debugging currently works for some
languages. In this case, Theia has to launch another instance of the
application in that language plugin's sidecar container, and connect
the debugger there. While this works for our sample projects, it does
have some drawbacks and poor UX:
- the application *has* to fit in the sidecar's memory limit or it
will get killed. In a general case it means the memory required for
the application has to be duplicated (e.g. 1024Mi for both main and
sidecar container) inflating workspace memory requirements
- there can be e.g. port conflicts if the user has run the typical
"run" task. In some debug configurations you have to look through a
stack trace to figure out the problem
Devfiles operating this way are e.g. Golang, Python, and .NET
The third mode can also be the most confusing to configure (especially
if you don't know the Che workspace structure already), as it's not
immediately clear where your application is running (`ps aux` in the
main container does not show it).
I think that following the 7.0 release, we should look into setting up
workspaces so that the second option is used whenever possible, and we
should try to set up Theia to lead users in this direction through the
launch.json autocompletions. In general, I don't think a user should
have to consider how many sidecars they are running, and what ends up
being run in which sidecar. It would be very confusing if e.g.
debugging kept crashing (due to memory limit) but regular "start"
tasks worked without issue.
Does anyone have any thoughts or other options in mind?
Cheers,
Angel
[1] - https://github.com/eclipse/che/issues/14091
(looking at it now, this needs to be rewritten to be more clear)
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev