Server Mode #145

dlanileonardo · 2018-04-18T07:04:56Z

The PR enable a server-mode option with doesn't wait for connection to start webserver, it's very sux when you are working with microservices, start a docker container justo to debug.
With this PR you can start rails and work, debugging when you want.

Is good to Docker an Vscode. 😉

jamesmosier · 2018-10-08T14:02:50Z

Anything I can do to get this PR merged in? @denofevil @mkrauskopf

paulodeleo · 2018-11-18T17:02:44Z

@dlanileonardo great addition, I'm using ruby-debug-ide from your repo until it gets merged.

By the way, what is your workflow for rails debugging with docker? I'm using restart: always with this ugly docker-compose command so when I disconnect from the debugger, killing the server, the container is restarted, getting rid of server.pid left by puma:

command: /bin/sh -c "rm -f /app/tmp/pids/server.pid && bundle exec rdebug-ide --server-mode --debug --host 0.0.0.0 --port 1234 -- bin/rails s -b 0.0.0.0"

ViugiNick · 2018-11-18T18:26:45Z

@paulodeleo
https://www.jetbrains.com/help/ruby/remote-debugging.html
You can run something like rdebug-ide --host 0.0.0.0 --port <port number> --dispatcher-port <port number> -- $COMMAND$ inside docker. And it will wait for connections to start your rails app.

paulodeleo · 2018-11-19T02:33:20Z

@ViugiNick that is what I'm already doing, and the whole point of this PR is to have a way to avoid making the server wait for a connection and be able to connect whenever you want, witch --server-mode option provides.

What I would also like to do is to be able to freely disconnect / reconnect the debugger without killing the server process. Much like the pry way of debugging workflow: when you need a breakpoint / REPL, just put a binding.pry line on any .rb file, save it, and the already running rails server will detect the breakpoint on the next page reload. Remove the call to binding.pry and it is gone. No need to restart the development rails server process with a special command line before of after needing to debug.

As I recently switched to VS Code and discovered ruby-debug-ide I don't know if such convenient way of debugging ruby is possible or if I'm missing something.

dlanileonardo · 2018-12-18T19:55:32Z

Hi @paulodeleo, I'm Using the branch feature/debugger of my fork vscode-ruby, because the repository owner vscode-ruby did not accepeted my request, anyway how can you observed the both don't accept my PR, so i think devs are too pround 😡, because that way the Workflow of the dev would look perfect as it should be.

In this branch, the debugger works exactly as u need it.

Just put feature/debugger branch in ~/.vscode/extensions

# my launcher.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen Local Debug",
      "type": "RubyDebugger",
      "request": "attach",
      "cwd": "${workspaceRoot}",
      "remoteHost": "127.0.0.1",
      "remotePort": "1231",
      "remoteWorkspaceRoot": "/app",
      "useBundler": true,
      "showDebuggerOutput": true
    }
  ]
}

My extension to Debug like a Boss 😎 and vscode-ruby 🤐 official to write code and lint.

Sorry for delay. 🙏🏻

paulodeleo · 2018-12-26T00:59:45Z

@dlanileonardo I'm getting this error when trying to start debugging with "type": "RubyDebugger" setting on launch.json:

Debug adapter process has terminated unexpectedly (read error).

Any idea of what is wrong?

Eusebius1920 · 2019-04-09T09:48:36Z

Any news on this? What are the blockers preventing this from getting merged?

ViugiNick · 2019-04-09T13:09:12Z

lib/ruby-debug-ide/commands/control.rb

@@ -136,11 +136,13 @@ def regexp
    end

    def execute
+      Debugger.require_multiprocess


isn't it already required by this moment?

ViugiNick · 2019-04-09T13:46:06Z

bin/rdebug-ide


 if options.attach_mode
+  Debugger.require_multiprocess


why do we need to require it here?

ViugiNick · 2019-04-09T13:47:12Z

lib/ruby-debug-ide/ide_processor.rb

@@ -90,6 +90,8 @@ def process_commands
        end
      end
    rescue ::Exception
+      # Workaround to Disconnect in Paused State
+      return @interface.command_queue << "finish" if $!.message === 'closed stream'


it's better to return after logging the error and backtrace

ViugiNick · 2019-04-09T16:42:12Z

@dlanileonardo @jamesmosier @paulodeleo @Eusebius1920 I don't fully understand what the difference between this approach and just disabling all breakpoints, keeping the debug session running. I'd like to note that if you initially launched the application with debugging, ruby virtual machine handlers will be installed for it(here

ruby-debug-ide/lib/ruby-debug-ide.rb

Line 100 in 235f8fa

bt = debug_load(abs_prog_script, options.stop, options.load_mode)

), which will significantly hit the overhead. And it doesn't matter if the socket is connected or not. So as for me it's better to use mute breakpoints functionality.

Eusebius1920 · 2019-04-09T17:02:12Z

@ViugiNick I am using ruby-debug-ide with visual studio code and there your abilities and hotkeys change if there is an active deugging session (to better suit your needs in such situations).

So I prefer having my debug-session running (always) and just attaching to the debugger (with visual-studio-code) if I really want to debug somewhere. If I start the ruby-debug-ide then I have to attach to it quickly and disconnect everytime to get the ruby-application up and running (so that I can re-attach later, when I need it). Otherwise ruby-debug-ide will just wait for a first connect and the ruby-application never gets started.

This is kind of annoying, that you have to attach just as a formality each time you start the debugger. Always running in debug-mode in visual studio code is not ideal either as it switches on purpose to the mentioned debug-mode when you connect to a debugger.

In the current setting I have two realistic settings:

Startup debugger only if I need it and run the ruby application without debugger if I dont need it.
Quickly connect each time I start the application only so that ruby-debug-ide spins up the application.

Eusebius1920 · 2019-04-09T17:02:45Z

I guess this wants to achieve exactly the same:
#167

jamesmosier · 2019-04-09T17:14:50Z

My use case is this: As a team we have a rails server running in Docker and not everyone uses vscode and not everyone wants to run ruby-debug. Therefore I wanted to have opt-in functionality for those of us who want to start up the rails server via docker, connect/disconnect the debugger, or not run it at all.

Either way not a huge deal, I understand the limitations/hesitations with this and my closed PR.

Thanks for your work on the extension!

ViugiNick · 2019-04-09T17:22:31Z

@jamesmosier But after all, in order to connect to the debug server, you still need to initially run the debug command, and not just the rails server. In other words, your command line will be different from a command line of people who are not going to debug the application.

Maybe you need something like that https://www.jetbrains.com/help/ruby/attaching-to-process.html
or like that https://blog.jetbrains.com/ruby/2018/05/rubymine-2018-2-eap-is-open/#attach_to_remote_processes

dlanileonardo · 2019-04-09T18:42:49Z

@ViugiNick When use Docker and Compose to development, and you have micro services with a lot of dependency's, restarting and alternate Instance Work and Instance Debug is a waste of time. With this PR, you server just run and you can use application debugging or not, the server listening debug port and you can attach it in anytime.

Example:

docker-compose.yml

mysql: ...

frontend: ...
  depends_on:
    - api
    - backend
    - cable

api:
  depends_on:
    - mysql
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/api.pid -p 3000 -b 0.0.0.0

sidekiq:
  depends_on:
    - cable
    - mysql
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/sidekiq.pid -p 3000 -b 0.0.0.0

cable:
  - api
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/cable.pid -p 3000 -b 0.0.0.0

In this example, today (without server mode) i needed change my docker-compose.yml for every debug or work instance in cable, sidekiq or api , this cause a restart of frontend unnecessarily.

ViugiNick · 2019-04-09T18:56:53Z

@dlanileonardo Why can't you just mute breakpoints and use the same docker-compose.yml?

ViugiNick · 2019-04-09T18:59:17Z

@dlanileonardo With such technique you can switch back to debugging just by unmuting them without reconnecting to debug session (as I mentioned here #145 (comment))

dlanileonardo · 2019-04-09T19:53:50Z

@dlanileonardo Why can't you just mute breakpoints and use the same docker-compose.yml?

@ViugiNick The problem is I need to connect every instance to this work, and open 3 windows vscode and connect it in cable, sidekiq and api.

Eusebius1920 · 2019-04-10T10:47:45Z

I guess the whole Pullrequest essentially boils down to this single line of code (or even only the the second half):

ruby-debug-ide/lib/ruby-debug-ide.rb

Line 103 in 57f4243

@proceed.wait(@mutex) unless server_mode

(Can you confirm this @dlanileonardo ?)

Is this adding so much complexity that it can become a burder that you have to drag along in further development (This is not meant to sound sarcastic but a serious question to those who know the internals of this project. I have no idea who this project internally works in any detail)

If not the discussion appears really unnecessary to me.

I am not happy with the naming (server_mode) or the description of the flag ("Tells that rdebug-ide is working in server mode"). I would it call no_wait or something like that.

ViugiNick · 2019-04-22T15:19:25Z

@dlanileonardo There are some unresolved comments in review.

iggycoder · 2019-06-15T02:59:35Z

Could we please just merge this now? Just as a side note...it's just a flag/option. Nobody is forced to use it. I also don't understand this discussion. I have a hard time understanding the current short comings though. I want to connect or disconnect to a debug server session without

starting/initializing the server only when I am connecting to the debug process the first time. Why coupling that behavior?
killing the server process when disconnecting

This is especially annoying in multi-server local dev setups with docker-compose.

I hope there's a way to have this PR merged.

ViugiNick · 2019-06-15T04:11:34Z

@iggycoder As you can see, there are a number of comments for this PR, thats why we don't merge it for now.

iggycoder · 2019-06-15T06:01:15Z

@ViugiNick Overlooked that. sorry.
@dlanileonardo Any chance to comment and/or change based on the review? I’d love to see that feature merged.

dlanileonardo mentioned this pull request Apr 19, 2018

Detach in Remote Mode rubyide/vscode-ruby#333

Closed

2 tasks

dlanileonardo force-pushed the master branch 5 times, most recently from 5975142 to 92d12d9 Compare April 24, 2018 17:11

Server Mode

57f4243

dlanileonardo force-pushed the master branch from 92d12d9 to 57f4243 Compare October 8, 2018 20:43

ViugiNick reviewed Apr 9, 2019

View reviewed changes

ViugiNick mentioned this pull request Aug 12, 2019

Added option to skip watting for start command #167

Merged

Merge remote-tracking branch 'upstream/master'

73c4185

dlanileonardo force-pushed the master branch from 6d12ed9 to 73c4185 Compare November 14, 2019 23:49

dlanileonardo closed this Apr 15, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Server Mode #145

Server Mode #145

dlanileonardo commented Apr 18, 2018 •

edited

Loading

jamesmosier commented Oct 8, 2018

paulodeleo commented Nov 18, 2018

ViugiNick commented Nov 18, 2018

paulodeleo commented Nov 19, 2018

dlanileonardo commented Dec 18, 2018

paulodeleo commented Dec 26, 2018

Eusebius1920 commented Apr 9, 2019

ViugiNick Apr 9, 2019

ViugiNick Apr 9, 2019

ViugiNick Apr 9, 2019

ViugiNick commented Apr 9, 2019

Eusebius1920 commented Apr 9, 2019

Eusebius1920 commented Apr 9, 2019

jamesmosier commented Apr 9, 2019

ViugiNick commented Apr 9, 2019

dlanileonardo commented Apr 9, 2019 •

edited

Loading

ViugiNick commented Apr 9, 2019

ViugiNick commented Apr 9, 2019 •

edited

Loading

dlanileonardo commented Apr 9, 2019 •

edited

Loading

Eusebius1920 commented Apr 10, 2019

ViugiNick commented Apr 22, 2019

iggycoder commented Jun 15, 2019

ViugiNick commented Jun 15, 2019

iggycoder commented Jun 15, 2019

Server Mode #145

Server Mode #145

Conversation

dlanileonardo commented Apr 18, 2018 • edited Loading

jamesmosier commented Oct 8, 2018

paulodeleo commented Nov 18, 2018

ViugiNick commented Nov 18, 2018

paulodeleo commented Nov 19, 2018

dlanileonardo commented Dec 18, 2018

paulodeleo commented Dec 26, 2018

Eusebius1920 commented Apr 9, 2019

ViugiNick Apr 9, 2019

Choose a reason for hiding this comment

ViugiNick Apr 9, 2019

Choose a reason for hiding this comment

ViugiNick Apr 9, 2019

Choose a reason for hiding this comment

ViugiNick commented Apr 9, 2019

Eusebius1920 commented Apr 9, 2019

Eusebius1920 commented Apr 9, 2019

jamesmosier commented Apr 9, 2019

ViugiNick commented Apr 9, 2019

dlanileonardo commented Apr 9, 2019 • edited Loading

ViugiNick commented Apr 9, 2019

ViugiNick commented Apr 9, 2019 • edited Loading

dlanileonardo commented Apr 9, 2019 • edited Loading

Eusebius1920 commented Apr 10, 2019

ViugiNick commented Apr 22, 2019

iggycoder commented Jun 15, 2019

ViugiNick commented Jun 15, 2019

iggycoder commented Jun 15, 2019

dlanileonardo commented Apr 18, 2018 •

edited

Loading

dlanileonardo commented Apr 9, 2019 •

edited

Loading

ViugiNick commented Apr 9, 2019 •

edited

Loading

dlanileonardo commented Apr 9, 2019 •

edited

Loading