ignoring SIGPIPE signal

[MislavSag]

Hi,

Thanks for this package, it helps a lot of people who are not experienced in cloud services.

I have deployed my API to Digital Ocean following your instructions for docker image building and deployment on DO.

I have tested the app and recognized that sometimes I get an error:

Response [https://xxx/liquidate]
  Date: 2024-01-29 12:10
  Status: 200
  Content-Type: application/json
  Size: 103 B

$error
$error[[1]]
[1] "Error in cat(conditionMessage(c), file = stderr(), sep = \"\"): ignoring SIGPIPE signal\n"

It seems there is a problem with outputting results.
I am not sure if this error is connected to the valve package or if the problem is somewhere else. I hope you know better.
The endpoint returns this error only on some occasions. Most of time I get output as expected but sometimes I get above error (for the same parameters and same code).

[JosiahParry]

Hey @MislavSag, I've not seen this!
Could it be related to this issue you think? https://stackoverflow.com/questions/28915838/piping-rscript-gives-error-after-output

Do you have a simple version of the api and the dockerfile you've used?

[JosiahParry]

Or related: futureverse/future#380

It could be that your Valve app is trying to use more threads than is available by your digitial ocean machine
https://valve.josiahparry.com/articles/using-valve-with-docker#a-note-on-number-of-workers

A note on number of workers
It is pretty tough to estimate the total number of worker threads available on a system. Right now, there is no check in place to see if your number of workers and connections exceeds the total number of threads available. If it does, there is a chance that calls to your Valve app may error out since there is thread contention. In general, its a good idea to only ask for what you need. For the smallest DigitalOcean compute, you should not exceed 3 workers and connections. Consult docs to see how many threads are available.

[MislavSag]

Here is the dockerfile:

# stage 1: install valve
FROM rust:slim AS builder
RUN cargo install valve-rs --no-default-features

# stage 2: configure the container to run plumber
FROM rocker/r-ver:4.3.1

ENV VALVE_HOST 0.0.0.0
ENV VALVE_PORT 8000

# always use RSPM
ENV RENV_CONFIG_REPOS_OVERRIDE https://packagemanager.rstudio.com/cran/latest

RUN apt-get update -qq && apt-get install -y --no-install-recommends \
   libcurl4-openssl-dev \
   libicu-dev \
   libsodium-dev \
   libssl-dev \
   make \
   zlib1g-dev \
   default-jdk \
   r-cran-rjava \
   libpq-dev \
   && apt-get clean

COPY renv.lock renv.lock
RUN Rscript -e "install.packages('renv')"
RUN Rscript -e "renv::restore()"
COPY plumber.R /api/plumber.R

# get binary from builder
COPY --from=builder /usr/local/cargo/bin/valve /usr/local/bin/

# open the port for valve
EXPOSE ${VALVE_PORT}

# Start Valve app
ENTRYPOINT valve -f /api/plumber.R -h $VALVE_HOST -p $VALVE_PORT --workers 5 --n-max 5 --check-unused 5 --max-age 300

I think the endpoints doesn't metter that much. One of the endpoint:

#* Ping IB
#* @param host:string The host for IB API (default: 'localhost')
#* @param port:integer The port for IB API (default: 5000)
#* @param strategy_name:string Optional strategy name
#* @param accunt_id:string Optional account ID
#* @param email_config:list Optional email configuration
#* @post /ping
function(host = "localhost",
         port = 5000,
         strategy_name = NULL,
         account_id = NULL,
         email_config = list()) {

  # Create an instance of the IB class with the provided parameters
  ib_instance <- IB$new(
    host = host,
    port = port,
    strategy_name = strategy_name,
    account_id = account_id,
    email_config = email_config,
    logger = NULL
  )

  # Call the liquidate method
  result <- tryCatch({
    ib_instance$get()
  }, error = function(e) {
    list(error = as.character(e))
  })

  # Return the result
  return(result)
}

[MislavSag]

Or related: HenrikBengtsson/future#380

It could be that your Valve app is trying to use more threads than is available by your digitial ocean machine https://valve.josiahparry.com/articles/using-valve-with-docker#a-note-on-number-of-workers

A note on number of workers
It is pretty tough to estimate the total number of worker threads available on a system. Right now, there is no check in place to see if your number of workers and connections exceeds the total number of threads available. If it does, there is a chance that calls to your Valve app may error out since there is thread contention. In general, its a good idea to only ask for what you need. For the smallest DigitalOcean compute, you should not exceed 3 workers and connections. Consult docs to see how many threads are available.

I have used Pro DO with 2 containers (24$ a month) and set 5 workers in as option in valve command

[JosiahParry]

What type of container are you using? Your configuration requires a minimum of 11 threads. 5 valve works, 5 possible plumber workers, and 1 pruning thread. That does not take into account any additional threads that might be spawned by your R processes. I'm not sure how you can check the number of threads available to you per container on DO

[MislavSag]

[MislavSag]

Do I have to set workers to 11 ?
I have checked links you provided above, but I am not sure that would solve my problem. Only thinkg I can thinkh of is to use try catch inside the endpoitn and repeat execution few times if it returnd above error.

[JosiahParry]

No, what I'm saying is that workers does not equal the total number of threads used by valve. Try giving this section a read: https://valve.josiahparry.com/#understanding-the-parameters

The maximum number of threads used by valve is workers + n_max + 1. In your case you have workers = 5, n_max = 5 so 5 + 5 + 1 = 11. Since you only have 1vCPU, I suspect that valve is trying to spawn more threads than is available. The number of processes that is used is different than the amount memory available.