RestRserve and async event loops/long running processes

[dereckmezquita]

EDIT: the scope of the question changed over time. I found that instead of running everything on the same thread I could spawn off a process for individual long running processes to run independently. The way one could allow for communication between RestRserve and these processes is to write to a separate file/database and periodically check there for status.

See: #216 (comment)

---

Hello,

I'm working on developing a trading bot in R and I'm encountering some challenges integrating asynchronous timers with the RestRserve API. I'm hoping to replicate functionality similar to what can be achieved in Node.js, but I'm running into some roadblocks.

Desired Functionality

Here's an example of what I'm trying to achieve, demonstrated in Node.js:

import express from 'express';

class TradeBot {
    isRunning = false;
    timer = null;

    run() {
        if (!this.isRunning) {
            this.isRunning = true;
            this.timer = setInterval(() => {
                console.log('running');
            }, 1000);
            console.log('Bot started');
        } else {
            console.log('Already running');
        }
    }

    stop() {
        if (this.isRunning) {
            clearInterval(this.timer);
            this.timer = null;
            this.isRunning = false;
            console.log('Bot stopped');
        } else {
            console.log('Bot is not running');
        }
    }
}

const bot = new TradeBot();
const app = express();

app.get('/start-bot', (req, res) => {
    bot.run();
    res.send('Bot started');
});

app.get('/stop-bot', (req, res) => {
    bot.stop();
    res.send('Bot stopped');
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

R Implementation Attempts

I've tried to implement this functionality in R using RestRserve along with the async package and later with the later package. Here are my attempts:

Using async package:

box::use(R6)
box::use(RestRserve[Application, BackendRserve])
box::use(async[async_timer, run_event_loop])

TradeBot <- R6$R6Class(
    "TradeBot",
    public = list(
        is_running = FALSE,
        timer = NULL,
        initialize = function() {
            self$is_running <- FALSE
            self$timer <- NULL
        },
        run = function() {
            if (!self$is_running) {
                self$is_running <- TRUE
                self$timer <- async_timer$new(1, function() {
                    cat("Running trade bot!\n")
                })
                cat("Bot started\n")
            } else {
                cat("Bot is already running\n")
            }
        },
        stop = function() {
            if (self$is_running) {
                self$is_running <- FALSE
                if (!is.null(self$timer)) {
                    self$timer$cancel()
                    self$timer <- NULL
                }
                cat("Bot stopped\n")
            } else {
                cat("Bot is not running\n")
            }
        }
    )
)

bot <- TradeBot$new()

app <- Application$new()

app$add_get("/start-bot", function(request, response) {
    bot$run()
    response$set_body("Bot started")
})

app$add_get("/stop-bot", function(request, response) {
    bot$stop()
    response$set_body("Bot stopped")
})

# Start the server
backend <- BackendRserve$new()

# Run the event loop
run_event_loop({
    backend$start(app, http_port = 8080, background = TRUE)
    cat("Server is running on port 8080\n")
    # this is to keep the main thread alive; I'm not sure if there's a better way
    # I am running RestRserve in the background but I'm not sure if I should instead run it on the main thread?
    while(TRUE) {
        Sys.sleep(1)
    }
})

Using later package:

box::use(R6)
box::use(RestRserve[Application, BackendRserve])
box::use(later)

create_interval <- function(callback, ms) {
    cancelled <- FALSE
    schedule_next <- function() {
        if (!cancelled) {
            callback()
            later$later(schedule_next, ms / 1000)
        }
    }
    later$later(schedule_next, ms / 1000)
    
    function() {
        cancelled <<- TRUE
    }
}

TradeBot <- R6$R6Class(
    "TradeBot",
    public = list(
        isRunning = FALSE,
        timer = NULL,

        run = function() {
            if (!self$isRunning) {
                self$isRunning <- TRUE
                self$timer <- create_interval(function() {
                    cat("running\n")
                }, 1000)
                cat("Running\n")
            } else {
                cat("Already running\n")
            }
        },

        stop = function() {
            if (self$isRunning) {
                self$timer()
                self$timer <- NULL
                self$isRunning <- FALSE
                cat("Stopped\n")
            } else {
                cat("Bot is not running\n")
            }
        }
    )
)

bot <- TradeBot$new()
app <- Application$new()

app$add_get("/start-bot", function(request, response) {
    bot$run()
    response$set_body("Bot started")
})

app$add_get("/stop-bot", function(request, response) {
    bot$stop()
    response$set_body("Bot stopped")
})

backend <- BackendRserve$new()
backend$start(app, http_port = 8080, background = TRUE)

# keep the thread open and sleep to avoid high CPU usage
while (TRUE) {
    later$run_now()
    Sys.sleep(0.1)
}

The Challenge

In both implementations, the asynchronous timers don't seem to execute within the RestRserve environment. The API endpoints work, but the scheduled tasks (printing "running" every second) never execute.

My understanding is that RestRserve utilises the parallel package and forking for handling requests in parallel, which prevents blocking when receiving multiple requests. However, this seems to be incompatible with the event loops provided by packages like async or later.

Questions and Advice Needed

1. Is it possible to integrate asynchronous timers (like those provided by async or later) with RestRserve in a way that allows for continuous execution alongside the API?
2. If not, are there alternative approaches within the RestRserve ecosystem that could achieve similar functionality?
3. I believe one potential solution might be to create two separate programmes - one for the bot logic and another for the REST API - and have them communicate via files or another method. However, I'd prefer to keep everything in memory, as this is for a trading bot where performance is crucial. Do you have any suggestions for achieving this within a single programme?
4. Are there any best practices or design patterns within RestRserve for managing long-running processes alongside API endpoints?

I'm open to any suggestions or advice on how to structure this system in a way that would work efficiently within the RestRserve framework. Thank you in advance for your help!

Additional Context

I recognise that the RestRserve community might not be intimately familiar with the async or later packages. My primary goal is to understand how RestRserve works and how we can leverage its capabilities to achieve the desired functionality. I'm particularly interested in:

1. How RestRserve handles long-running processes or background tasks.
2. Whether there are built-in mechanisms in RestRserve for periodic task execution (similar to the setInterval function in JavaScript).
3. If RestRserve has its own event loop or scheduling system that could be used for this purpose.

Any insights into RestRserve's architecture and how it might accommodate (or provide alternatives to) the kind of asynchronous, timer-based operations I'm trying to implement would be greatly appreciated. I'm open to restructuring my approach to better align with RestRserve's design philosophy and capabilities.

I originally posted a similar discussion to the async package discussion board, but I believe the core of the issue might be more related to RestRserve's architecture.

[dselivanov]

Hi Dereck. I tried to experiment with 'later' package and event loop events. I don't think it will work with Rserve backend due to the way it handles requests with fork. However I do believe it will work if someone will implement 'httpuv' backend. Shouldn't be difficult.

…

On Mon, Aug 12, 2024, 07:38 Dereck Mezquita ***@***.***> wrote: Hello, I'm working on developing a trading bot in R and I'm encountering some challenges integrating asynchronous timers with the RestRserve API. I'm hoping to replicate functionality similar to what can be achieved in Node.js, but I'm running into some roadblocks. Desired Functionality Here's an example of what I'm trying to achieve, demonstrated in Node.js: import express from 'express'; class TradeBot { isRunning = false; timer = null; run() { if (!this.isRunning) { this.isRunning = true; this.timer = setInterval(() => { console.log('running'); }, 1000); console.log('Bot started'); } else { console.log('Already running'); } } stop() { if (this.isRunning) { clearInterval(this.timer); this.timer = null; this.isRunning = false; console.log('Bot stopped'); } else { console.log('Bot is not running'); } }} const bot = new TradeBot();const app = express(); app$get('/start-bot', (req, res) => { bot.run(); res.send('Bot started');}); app$get('/stop-bot', (req, res) => { bot.stop(); res.send('Bot stopped');}); app.listen(3000, () => { console.log('Server is running on port 3000');}); R Implementation Attempts I've tried to implement this functionality in R using RestRserve along with the async <https://github.com/gaborcsardi/async> package and later with the later <https://github.com/r-lib/later> package. Here are my attempts: Using async package: box::use(R6)box::use(RestRserve[Application, BackendRserve])box::use(async[async_timer, run_event_loop]) TradeBot <- R6$R6Class( "TradeBot", public = list( is_running = FALSE, timer = NULL, initialize = function() { self$is_running <- FALSE self$timer <- NULL }, run = function() { if (!self$is_running) { self$is_running <- TRUE self$timer <- async_timer$new(1, function() { cat("Running trade bot!\n") }) cat("Bot started\n") } else { cat("Bot is already running\n") } }, stop = function() { if (self$is_running) { self$is_running <- FALSE if (!is.null(self$timer)) { self$timer$cancel() self$timer <- NULL } cat("Bot stopped\n") } else { cat("Bot is not running\n") } } ) ) bot <- TradeBot$new() app <- Application$new() app$add_get("/start-bot", function(request, response) { bot$run() response$set_body("Bot started") }) app$add_get("/stop-bot", function(request, response) { bot$stop() response$set_body("Bot stopped") }) # Start the serverbackend <- BackendRserve$new() # Run the event loop run_event_loop({ backend$start(app, http_port = 8080, background = TRUE) cat("Server is running on port 8080\n") # this is to keep the main thread alive; I'm not sure if there's a better way # I am running RestRserve in the background but I'm not sure if I should instead run it on the main thread? while(TRUE) { Sys.sleep(1) } }) Using later package: box::use(R6)box::use(RestRserve[Application, BackendRserve])box::use(later) create_interval <- function(callback, ms) { cancelled <- FALSE schedule_next <- function() { if (!cancelled) { callback() later$later(schedule_next, ms / 1000) } } later$later(schedule_next, ms / 1000) function() { cancelled <<- TRUE } } TradeBot <- R6$R6Class( "TradeBot", public = list( isRunning = FALSE, timer = NULL, run = function() { if (!self$isRunning) { self$isRunning <- TRUE self$timer <- create_interval(function() { cat("running\n") }, 1000) cat("Running\n") } else { cat("Already running\n") } }, stop = function() { if (self$isRunning) { self$timer() self$timer <- NULL self$isRunning <- FALSE cat("Stopped\n") } else { cat("Bot is not running\n") } } ) ) bot <- TradeBot$new()app <- Application$new() app$add_get("/start-bot", function(request, response) { bot$run() response$set_body("Bot started") }) app$add_get("/stop-bot", function(request, response) { bot$stop() response$set_body("Bot stopped") }) backend <- BackendRserve$new()backend$start(app, http_port = 8080, background = TRUE) # keep the thread open and sleep to avoid high CPU usagewhile (TRUE) { later$run_now() Sys.sleep(0.1) } The Challenge In both implementations, the asynchronous timers don't seem to execute within the RestRserve environment. The API endpoints work, but the scheduled tasks (printing "running" every second) never execute. My understanding is that RestRserve utilises the parallel package and forking for handling requests in parallel, which prevents blocking when receiving multiple requests. However, this seems to be incompatible with the event loops provided by packages like async or later. Questions and Advice Needed 1. Is it possible to integrate asynchronous timers (like those provided by async or later) with RestRserve in a way that allows for continuous execution alongside the API? 2. If not, are there alternative approaches within the RestRserve ecosystem that could achieve similar functionality? 3. I believe one potential solution might be to create two separate programmes - one for the bot logic and another for the REST API - and have them communicate via files or another method. However, I'd prefer to keep everything in memory, as this is for a trading bot where performance is crucial. Do you have any suggestions for achieving this within a single programme? 4. Are there any best practices or design patterns within RestRserve for managing long-running processes alongside API endpoints? I'm open to any suggestions or advice on how to structure this system in a way that would work efficiently within the RestRserve framework. Thank you in advance for your help! Additional Context I recognise that the RestRserve community might not be intimately familiar with the async <https://github.com/gaborcsardi/async> or later <https://github.com/r-lib/later> packages. My primary goal is to understand how RestRserve works and how we can leverage its capabilities to achieve the desired functionality. I'm particularly interested in: 1. How RestRserve handles long-running processes or background tasks. 2. Whether there are built-in mechanisms in RestRserve for periodic task execution (similar to the setInterval function in JavaScript). 3. If RestRserve has its own event loop or scheduling system that could be used for this purpose. Any insights into RestRserve's architecture and how it might accommodate (or provide alternatives to) the kind of asynchronous, timer-based operations I'm trying to implement would be greatly appreciated. I'm open to restructuring my approach to better align with RestRserve's design philosophy and capabilities. I originally posted a similar discussion to the async <gaborcsardi/async#83 (reply in thread)> package discussion board, but I believe the core of the issue might be more related to RestRserve's architecture. — Reply to this email directly, view it on GitHub <#216>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHC5XK5WJZBQWWH2A3HHJLZQ7YXBAVCNFSM6AAAAABMLE4MHWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGA2DAMBUGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dereckmezquita]

@dselivanov thank you so much. Can you elaborate please? I would love to make a contribution to RestRserve :)

Here's what I understood. RestRserve is built on Rserve for TCP/IP. In order to be able to handle multiple requests and not block the main thread RestRserve creates 2 forks where one is used as a manager and the second for compute. When one is blocked another is created. This is done with the parallel package.

What you're suggesting is to implement httpuv as a TCP/IP server for RestRserve. This being built on libuv and having a real event loop would allow me the functionality I am requesting!

Is my understanding correct? How could I work on this? Do you have guidlines for contributions?

[s-u]

@dereckmezquita That's not really how it works - RserRserve registers the http hander (.http.request) and then starts the server (Rserve::run.Rserve). Have a look at BackendRserve.R. To create a new backed for httpuv you'd write a new Backend subclass which uses httpuv::startServer instead of Rserve::run.Rserve and define app$call instead of .http.request, re-mapping the calling conventions using the other functions in the Backend class.

[s-u]

BTW: if you really don't care about performance then you could simply use the built-in HTTP server in R (i.e., no need for httpuv) -- it uses the same .http.request API as Rserve (in fact it's based on the same code) so it would be really small change to make. (I'm still not convinced that this makes sense - see the post below, but if you insist ;))

[s-u]

Dereck, the Rserve back-end is a server with parallel processes - it is not just an R session, which is why it is scalable. The server does not use R to accept connections. However, it means that the moment you start it, only clients get to execute R code, the server is in a way not R anymore*.

Unfortunately, from your post it is unclear what you are actually trying to achieve in your application - R is fully synchronous, so there is no way to implement real "async" - the packages you mention are just a hack that hooks into what would be normally user typing commands in R and uses that to execute code synchronously. However, with RestRserve there are potentially many different R sessions running at a given point, so it makes no sense to think of anything happening in one session. Also each client request can be handled by a different process.

If you are interested in some kind of synchronized state, then you can use redis server or similar (but that's just guessing what you are trying to do).

As Dmitry said, if you don't care about performance or scalability then you can use a single R process (e.g., via httpuv) and that becomes the synchonization point as then R is fully serial (with the corresponding performance and scalability limitations).

(*) - it is in principle possible to mesh the R event loop and the Rserve server loop - i.e. the loop that waits for new connections. This is typically not desired in deployment as it makes the server more fragile and has performance implications (when anything is evaluated in the R loop the server cannot accept new client connections). Also note that this won't affect existing connections by design (those have already detached from the server), but if that still works in your use-case, then it's something I have ready to go so could enable it if you want to test it.

[s-u]

@dereckmezquita If you want to give the above (*) a try, install Rserve 1.8-15 (install.packages("Rserve",repos="https://rforge.net")) and add background=TRUE argument to the call of run.Rserve(). That will mesh the server loop with the main loop of the session you're in.

@dselivanov This may be possibly an alternative to the current background option in RserveBackend - even though it has different semantics (currently, the background process doesn't change, but if done this way it will reflect changes to the application - which is possibly beneficial?).

[dereckmezquita]

@dselivanov and @s-u

First and foremost, I want to express my gratitude for taking the time to address my questions and provide insightful guidance. Your explanations have clarified my understanding of RestRserve and the R language.

A contribution to RestRserve

I'm particularly intrigued by the suggestion to implement an httpuv backend for RestRserve. Could you provide more details on how this might be approached? Specifically:

1. What would be the key steps in creating a new Backend subclass for httpuv?
2. How would the request/response handling differ from the current Rserve implementation?
3. Are there any specific challenges or considerations we should be aware of if integrating httpuv with RestRserve's existing structure?
4. It seems like RestRserve is specifically built around Rserve, would adding httpuv be appropriate or even desirable? Might it be better to build a separate RestHttpuv pacakge?

Working demo of async bots + http server for communication (REST API?)

After looking into the suggestions made here about httpuv I was able to put together a minimal working demo to illustrate something similar to what I'm trying to achieve. I will give a more detailed explanation of what I'm trying to after.

box::use(R6)
box::use(httpuv)
box::use(later)
box::use(jsonlite)

# Trading Bot class
TradingBot <- R6$R6Class(
    "TradingBot",
    public = list(
        is_running = FALSE,
        timer = NULL,

        run = function() {
            if (!self$is_running) {
                self$is_running <- TRUE
                self$schedule_next()
                cat("Bot started\n")
            } else {
                cat("Bot is already running\n")
            }
        },

        stop = function() {
            if (self$is_running) {
                cat("Bot stopped\n")
                self$is_running <- FALSE
                if (!is.null(self$timer)) {
                    self$timer$cancel()
                    self$timer <- NULL
                }
            } else {
                cat("Bot is not running\n")
            }
        },

        schedule_next = function() {
            if (self$is_running) {
                cat("Trading bot is running...\n")
                # Schedule the next execution
                self$timer <- later$later(~self$schedule_next(), delay = 1)
            }
        }
    )
)

# Create bot instance
bot <- TradingBot$new()

# Define the application
app <- list(
    call = function(req) {
        if (req$PATH_INFO == "/start-bot") {
            bot$run()
            response <- list(status = "Bot started")
        } else if (req$PATH_INFO == "/stop-bot") {
            bot$stop()
            response <- list(status = "Bot stopped")
        } else {
            response <- list(status = "Unknown endpoint")
        }

        list(
            status = 200L,
            headers = list('Content-Type' = 'application/json'),
            body = jsonlite$toJSON(response, auto_unbox = TRUE)
        )
    }
)

# Start the server
cat("Starting server on http://127.0.0.1:8080\n")
server <- httpuv$startServer("127.0.0.1", 8080, app)

httpuv$service(timeout = Inf)

(base) work@Derecks-MacBook-Air server % Rscript dev/httpuv/httpuv-later.R
- The project is out-of-sync -- use `renv::status()` for details.
Starting server on http://127.0.0.1:8080
Trading bot is running...
Bot started
Trading bot is running...
Trading bot is running...
Trading bot is running...
Bot stopped
Trading bot is running...
Bot started
Trading bot is running...
Trading bot is running...
Trading bot is running...
Trading bot is running...
Trading bot is running...
Trading bot is running...
Bot stopped

What am I trying to build? A trade bot

I hope not to bore you with too much information but here are a few more details as to what I am planning; to further clarify my goal.

Please feel free to correct me, realign, push me or correct any misconceptions I might have. My goal is to get a working programme, as such my ego is disposable and I seek whatever guidance you could impart.

I want to build a programme in R that will function as a trading bot. What would this programme to do? I would have 2 main parts.

1. An instance of a BotManager class
   • This BotManager would have methods such as:
     • add_bot: this would add a bot instance to the fleet; a list of bots in various states
     • start_bot: this would when passed the ID for a bot start the bot running
     • terminate_bot: would stop the bot and delete it from the list
   • I would have a class called TradeBot each bot would have methods such as:
     • run_trade_loop: this would start the bot running with whatever config it was given on instantiation. It would pull data from whatever broker, run statistical analysis and ML on it then make a decision to buy, sell, or hold; it would submit this decision with the broker
     • stop_trade_loop: would simply stop the bot
2. Run a REST API with different end points; these end points would serve to communicate with the bot; i.e. I would pass the BotManager instance to the REST API end points

Now for how I understand this could work taking into consideration R's synchronous nature. I believe there could be two approaches to this, but one is more clear than the other.

1. Fork R processes and create new threads in order to run new bots; this would still require an event loop as when we create a bot we want the trading loop to run on an interval and repeat every X amount of time.
2. Run the whole programme on one event loop; this would allow me to run the REST API + any of the bots and their trading loops. I believe this would be blocking to some extent so if one of the trading bots has to run calculations for 5 mins the whole programme would be blocked for 5 mins and if I were running other bots/the REST API would not compute/respond for that amount of time.

Despite being simple, the above example I gave/the nodeJS example demonstrates the concept I want to build off of. A bot that can run continuously on an interval + a REST API also responding to HTTP requests. It seems to work as expected, running on a single thread with an event loop, similar to how Node.js operates.

I plan to run this bot for myself and academic purposes so it doesn't have to scale for public use. I think this works nicely for now because of the small scale of the programme.

httpuv + later == NodeJS event loop?

After some research I found that httpuv lists the later pacakge in it's DESCRIPTION as a dependency. I read the docs in the later package and found that when you run later to schedule a call back it searches for the global event loop and hooks into that:

• https://r-lib.github.io/later/reference/create_loop.html
• https://r-lib.github.io/later/reference/later.html

I am still learning how httpuv uses later but that might be why they work nicely together as they're using the same mechanism for an event loop CC: @wch. I believe that if I use later + httpuv they use the same event loop (https://github.com/search?q=repo%3Arstudio%2Fhttpuv+later%3A%3A&type=code).

So my conclusion is that if I use httpuv + later I am in fact creating an event loop in my R programme. So if my understanding is correct, this is in a way equivalent to NodeJS.

Now I have not faced any scaling issues yet, but I am starting to wonder if I had written my whole programme in NodeJS if it would face the same scaling issues as R with this event loop.

This next comment ventures into potential ignorance: in my mind the best would be if we could have the best of both worlds, i.e. forking + async event loops so that when I create a bot it runs on its own thread with it's own event loop.

Conclusion

Given my example, I'm curious about your thoughts on:

1. Whether a similar implementation could be achieved within RestRserve, perhaps through the suggested httpuv backend.
2. Any potential drawbacks or limitations of this approach that I should be aware of.

Thank you again for your time and expertise. Your insights have been invaluable helping my understanding of these complex topics.

[s-u]

I'm wondering if you are overcomplicating things here. Since you want to simply run some bots, that task has nothing to do with the REST API, so it is a simply a process management task. Those bots can simply be separate R processes which launch, do the work and store the results. Your REST API simply spawns those bots (no forking needed), reads the results from the bots and kills them if needed. There are really no timers involved at all in this scenario AFAIK - it's just process bookkeeping. The client has no need to talk to the bots directly it just talks to the REST service which reads and relays the results - and the endpoints are simple R functions which you can comfortably write with RestRserve without any special considerations. Or am I missing something here?

(FWIW there is only one event loop in R [due to its serial nature], so yes, everyone uses the same loop).

PS: You could as well just write the REST part in NodeJS since you seem comfortable with it and only spawn R for the bots ...

[dereckmezquita]

@s-u we've deviated from RestRserve at this point so thank you for entertaining my idea and discussing.

I see, yes you're right. I am overcomplicating it to some extent. This can indeed be split up into two separate programmes.

1. BotManager/TradeBots if no bots are running then it is off and does nothing.
   • I could even spawn each bot in a separate thread and just have the BotManager as a main thread to control these/access them.
2. The REST API for sending commands to the BotManager.

You say that there are no timers involved but I think either I didn't understand or I didn't explain clearly enough. So when spawned a bot should run on an interval. What I mean by that is it will every 10 seconds get data from the broker, run statistics on it, make a call (buy, sell or hold) then wait until the next cycle.

So in my mind each bot should have it's own event loop and thread.

I think this architecture would be better than having the whole thing run on the same thread/event loop.

My motivations for this project are two pronged, with one of those being the academic aspects of it. So indeed I could write parts of it in NodeJS or some other language but I really wanted to push R and see what can be done with it.

[s-u]

Dereck, what I meant by saying there is no timer is simply that the bot itself can do Sys.sleep(10) as it has nothing else to do in between, so no need for any special asynchronicity -- if you go with the approach I described where they the bots are simply separate R processes.

Also I may not have been clear - in what I described the REST API is the bot manager - it's only the bots that are separate R processes. That way it's really clean and easy to manage. The point with NodeJS was rather that it doesn't really matter which language you use - you can use R, that's perfectly fine. Also it means you can use any framework you desire since it doesn't matter (whether the built-in server, RestRserve, httpuv, ... all would work here).

[dereckmezquita]

@s-u I think I got something semi-satisfactory working with your ideas and help. Thank you very much! It's not perfect, it throws a weird error (probably something I did wrong with my use of parallel); I'm still debugging.

I'm happy as this brings the conversation back to RestRserve and how to use it to spawn long running processes from end points :)

I used:

• RestRserve for the REST API
• parallel for separate processes; I saw you're an author here so thank you :)
• An Rds file (simulates database I will use SQLite)
• later for async event loop, you're right I could just use a recursive function with Sys.sleep however, in my full application might want to execute other processes for a single bot on the same thread - this way my bot could run the trading loop and then do other actions in between.

I'll explain what I have below.

• TradeBot
  • id: UUID used to track and manage bots
  • start: starts bot; changes status to running and calls the recursive async loop
  • stop: changes status to stop and cancels the timer
  • run: async event loop driven method for executing trading logic inside, call broker API, run stats, report a signal; method also checks if run status has changed every call
  • check_status: helper method for checking if it should continue running
• Rds file serves to simulate database where I'll save data I will use SQLite

When I hit the start-bot end point it starts a bot in a separate process and saves the status to the Rds file. Every run loop the trade bot checks if the status is still there, if it has been deleted from this is a signal to stop running.

box::use(RestRserve[Application, BackendRserve])
box::use(R6)
box::use(later)
box::use(parallel)
box::use(uuid)

# Define the TradeBot class
TradeBot <- R6$R6Class(
    "TradeBot",
    public = list(
        is_running = FALSE,
        timer = NULL,
        id = NULL,
        bot_file = NULL,
        initialize = function(id, bot_file) {
            self$bot_file <- bot_file
            self$is_running <- FALSE
            self$timer <- NULL
            self$id <- id
        },
        start = function() {
            if (!self$is_running) {
                self$is_running <- TRUE
                private$run()
                cat(sprintf("Bot %s started\n", self$id))
            } else {
                cat(sprintf("Bot %s is already running\n", self$id))
            }
        },
        stop = function() {
            if (self$is_running) {
                self$is_running <- FALSE
                if (!is.null(self$timer)) {
                    self$timer()
                    self$timer <- NULL
                }
                cat(sprintf("Bot %s stopped\n", self$id))
            } else {
                cat(sprintf("Bot %s is not running\n", self$id))
            }
        }
    ),
    private = list(
        check_status = function() {
            tryCatch({
                processes <- readRDS(self$bot_file)
                if (is.null(processes[[self$id]])) {
                    self$stop()
                    return(FALSE)
                }
                return(TRUE)
            }, error = function(e) {
                cat(sprintf("Error checking status for Bot %s: %s\n", self$id, e$message))
                return(FALSE)
            })
        },
        run = function() {
            if (!private$check_status()) {
                return(NULL)
            }
            cat(sprintf("Bot %s is running\n", self$id))
            self$timer <- later$later(function() {
                tryCatch({
                    private$run()
                }, error = function(e) {
                    cat(sprintf("Error in Bot %s: %s\n", self$id, e$message))
                    self$stop()
                })
            }, 1, loop = later$global_loop())
        }
    )
)


# Use file to store bot processes; simulates database
bot_file <- "bot_processes.Rds"
if (!file.exists(bot_file)) {
    processes <- list()
    saveRDS(processes, file = bot_file)
}

# Function to start a new bot process
start_bot_process <- function(bot_id) {
    processes <- readRDS(bot_file)
    if (!is.null(processes[[bot_id]])) {
        return(FALSE) # Bot already exists
    }

    bot_process <- parallel$mcparallel({
        tryCatch({
            bot <- TradeBot$new(bot_id, bot_file)
            bot$start()
            while (bot$is_running) {
                later$run_now(all = TRUE, loop = later$global_loop())
                Sys.sleep(0.1)  # Add a small delay to prevent excessive CPU usage
            }
        }, error = function(e) {
            cat("Error in bot process:", e$message, "\n")
        }, finally = {
            cat(sprintf("Bot %s process exiting\n", bot_id))
        })
    })

    processes[[bot_id]] <- list(pid = bot_process$pid)
    saveRDS(processes, file = bot_file)
    return(TRUE)
}

# Function to stop a bot process
stop_bot_process <- function(bot_id) {
    processes <- readRDS(bot_file)
    if (is.null(processes[[bot_id]])) {
        return(FALSE) # Bot doesn't exist
    }

    # Signal the bot to stop
    processes[[bot_id]] <- NULL
    saveRDS(processes, file = bot_file)
    
    # Wait for the process to finish
    Sys.sleep(2)
    
    return(TRUE)
}

# Create the REST API application
app <- Application$new()

app$add_get("/", function(request, response) {
    response$set_body("Welcome to the Trade Bot API")
})

app$add_get("/start-bot", function(request, response) {
    bot_id <- request$parameters_query[["id"]]
    if (is.null(bot_id)) {
        bot_id <- uuid$UUIDgenerate()
    }
    if (start_bot_process(bot_id)) {
        response$set_body(sprintf("Bot %s started", bot_id))
    } else {
        response$set_status_code(400)
        response$set_body(sprintf("Bot %s already running", bot_id))
    }
})

app$add_get("/stop-bot", function(request, response) {
    bot_id <- request$parameters_query[["id"]]
    if (is.null(bot_id)) {
        response$set_status_code(400)
        response$set_body("Bot ID is required")
        return(NULL)
    }
    if (stop_bot_process(bot_id)) {
        response$set_body(sprintf("Bot %s stopped", bot_id))
    } else {
        response$set_status_code(400)
        response$set_body(sprintf("Bot %s not found or could not be stopped", bot_id))
    }
})

app$add_get("/list-bots", function(request, response) {
    processes <- readRDS(bot_file)
    bot_list <- names(processes)
    response$set_body(paste("Running bots:", paste(bot_list, collapse = ", ")))
})

# Start the server
backend <- BackendRserve$new()
backend$start(app, http_port = 8080)

It works but I did something wrong; it throws this error from parallel:

(base) work@Derecks-MacBook-Air dev % Rscript rest-bots-independent/index.R 
{"timestamp":"2024-08-14 21:05:32.656289","level":"INFO","name":"Application","pid":32644,"msg":"","context":{"http_port":8080,"endpoints":{"HEAD":["/","/start-bot","/stop-bot","/list-bots"],"GET":["/","/start-bot","/stop-bot","/list-bots"]}}}
-- running Rserve in this R session (pid=32644), 2 server(s) --
(This session will block until Rserve is shut down)
Bot 1a861785-533f-4cf1-b668-6986da137c23 is running
Bot 1a861785-533f-4cf1-b668-6986da137c23 started
Bot 1a861785-533f-4cf1-b668-6986da137c23 is running
Bot 1a861785-533f-4cf1-b668-6986da137c23 is running
Bot 1a861785-533f-4cf1-b668-6986da137c23 is running
Bot 1a861785-533f-4cf1-b668-6986da137c23 stopped
Bot 1a861785-533f-4cf1-b668-6986da137c23 process exiting

 *** caught bus error ***
address 0x102f47028, cause 'invalid alignment'

 *** caught  ***
Bot 158977f5-0cd6-4302-ad01-3e905f79387e is running
Bot 158977f5-0cd6-4302-ad01-3e905f79387e started
Bot 158977f5-0cd6-4302-ad01-3e905f79387e is running
Bot 158977f5-0cd6-4302-ad01-3e905f79387e is running
Bot 158977f5-0cd6-4302-ad01-3e905f79387e is running
Bot 158977f5-0cd6-4302-ad01-3e905f79387e stopped
Bot 158977f5-0cd6-4302-ad01-3e905f79387e process exiting

 *** caught segfault ***
address 0x4000000102f47018, cause 'invalid permissions'
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 is running
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 started
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 is running
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 is running
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 stopped
Bot 3a472bc4-8a32-4980-9120-52985ce41ce5 process exiting

 *** caught segfault ***
address 0x4000000102f47228, cause 'invalid permissions'
Bot 6259a15d-03f1-4174-8155-e5e4677811aa is running
Bot 6259a15d-03f1-4174-8155-e5e4677811aa started
Bot 6259a15d-03f1-4174-8155-e5e4677811aa is running
Bot 6259a15d-03f1-4174-8155-e5e4677811aa stopped
Bot 6259a15d-03f1-4174-8155-e5e4677811aa process exiting

 *** caught segfault ***
address 0x4000000102f47228, cause 'invalid permissions'
{"timestamp":"2024-08-14 21:06:37.898974","level":"ERROR","name":"Application","pid":33791,"msg":"","context":{"request_id":"fc61d990-5aaa-11ef-9041-8ad61b804eb5","message":{"error":"bad value","call":"deparse(call, nlines = 1L)","traceback":["FUN(request, response)","start_bot_process(bot_id)",["parallel$mcparallel({","    tryCatch({","        bot <- TradeBot$new(bot_id, bot_file)","        bot$start()","        while (bot$is_running) {","            later$run_now(all = TRUE, loop = later$global_loop())","            Sys.sleep(0.1)","        }","    }, error = function(e) {","        cat(\"Error in bot process:\", e$message, \"\\n\")","    }, finally = {","        cat(sprintf(\"Bot %s process exiting\\n\", bot_id))","    })","})"],"mcexit(1L, structure(\"fatal error in wrapper code\", class = \"try-error\"))","try(sendMaster(send, FALSE), silent = TRUE)",["tryCatch(expr, error = function(e) {","    call <- conditionCall(e)","    if (!is.null(call)) {","        if (identical(call[[1L]], quote(doTryCatch))) ","            call <- sys.call(-4L)","        dcall <- deparse(call, nlines = 1L)","        prefix <- paste(\"Error in\", dcall, \": \")","        LONG <- 75L","        sm <- strsplit(conditionMessage(e), \"\\n\")[[1L]]","        w <- 14L + nchar(dcall, type = \"w\") + nchar(sm[1L], type = \"w\")","        if (is.na(w)) ","            w <- 14L + nchar(dcall, type = \"b\") + nchar(sm[1L], ","                type = \"b\")","        if (w > LONG) ","            prefix <- paste0(prefix, \"\\n  \")","    }","    else prefix <- \"Error : \"","    msg <- paste0(prefix, conditionMessage(e), \"\\n\")","    .Internal(seterrmessage(msg[1L]))","    if (!silent && isTRUE(getOption(\"show.error.messages\"))) {","        cat(msg, file = outFile)","        .Internal(printDeferredWarnings())","    }","    invisible(structure(msg, class = \"try-error\", condition = e))","})"],"tryCatchList(expr, classes, parentenv, handlers)","tryCatchOne(expr, names, parentenv, handlers[[1L]])","value[[3L]](cond)","deparse(call, nlines = 1L)"]}}}
^CCaught break signal, shutting down Rserve.
[1] TRUE

Edit: posted my minimal example to stackoverflow for help debugging segfault: https://stackoverflow.com/questions/78873423/r-segfault-parallel-process-with-restrserve-and-mcparallel

[dereckmezquita]

I started a new discussion here where I explained that I was able to solve the segmentation fault by setting detached = TRUE.

#217

start_bot_process <- function(bot_id) {
    processes <- readRDS(bot_file)
    if (!is.null(processes[[bot_id]])) {
        return(FALSE) # Bot already exists
    }

    bot <- TradeBot$new(bot_id, bot_file)
    bot_process <- parallel$mcparallel({
        tryCatch({
            bot$start()
            while (bot$is_running) {
                later$run_now(all = TRUE, loop = later$global_loop())
                Sys.sleep(0.1)  # Add a small delay to prevent excessive CPU usage
            }
        }, error = function(e) {
            cat("Error in bot process:", e$message, "\n")
        }, finally = {
            cat(sprintf("Bot %s process exiting\n", bot_id))
        })
    }, detached = TRUE)

    processes[[bot_id]] <- list(pid = bot_process$pid)
    saveRDS(processes, file = bot_file)
    return(TRUE)
}

[s-u]

Please note that it is not safe fork a client (it is communicating at the time!) - as noted in our earlier discussion, you want to start a new process for the bots, you don't want to fork the REST process (see the discussion - the whole point is that the REST part is entirely independent).

[dereckmezquita]

@s-u yes indeed, thank you for the patience; you've told me this a couple of times!

Can you recommend a way to do inter-programme communications?

Edit: I'm looking for someone more experienced to point me to what the right way of doing this would be. So thank you it's greatly appreciated.

I've come up with a few possible candidates:

• Redis
• Sockets
• File based
• Database

The pattern I keep seeing is that it is not going to be possible to reach into another process and update a variable's value, I will have to implement some kind of polling to check if any varables have been updated.

[s-u]

Depends on what you need - I was suggesting redis (aka redict/valkey) originally which has the very nice benefit that it has a queuing system as well so it's easy to implement a pool of workers. However, looking at your code I don't think you need IPC- you are already using files so that's the easiest and works well here: the REST process simply loads the state file save by the worker. The only details to note is that you want to update the files atomically (so either just append [like logs] or use the equivalent of > foo.new && mv foo.new foo).