Hi,
I'm facing an issue with the IPC package, as I use it for emitting some signal from ExtendedTask + mirai processes to the main Shiny app, I realized that the refreshing rate of the queue (defined with queue$consumer$start(rate) ) could make skip some messages if the messages are emitted too fast.
Actually I found a workaround but I was surprised that the queue was not persistent until the message was read. Is it the normal behavior ?
Here is a minimal example of what I am talking about.
In this example, we emit a number every 100ms, but the consumer reads the queue only every 200ms. We can see in the console that it skips 1 on 2 values. If we change the consumer rate to less than 100ms, all values are output.
Thanks for your feedback, as this behaviour (keeping track of the queue) could be useful for logs or just to be sure we don't miss any communication.
By the way, the package is awesome and I use it all the time ! Thanks for all the work done !!
library(shiny)
library(ipc)
library(mirai)
ui <- fluidPage(
actionButton("run", "Start Task"),
)
server <- function(input, output, session) {
# IPC queue
queue <- shinyQueue()
queue$consumer$start(200) # change to less than 100 to get all values
log_text <- reactiveVal("")
# Append to log
observeEvent(log_text(), print(log_text()))
task <- ExtendedTask$new(function( queue){
mirai({
for (i in 1:10) {
Sys.sleep(0.1)
queue$producer$fireAssignReactive("log_text", i)
}
}, queue = queue)
})
# Trigger async task
observeEvent(input$run, {
task$invoke(queue)
})
}
shinyApp(ui, server)
Hi,
I'm facing an issue with the IPC package, as I use it for emitting some signal from ExtendedTask + mirai processes to the main Shiny app, I realized that the refreshing rate of the queue (defined with queue$consumer$start(rate) ) could make skip some messages if the messages are emitted too fast.
Actually I found a workaround but I was surprised that the queue was not persistent until the message was read. Is it the normal behavior ?
Here is a minimal example of what I am talking about.
In this example, we emit a number every 100ms, but the consumer reads the queue only every 200ms. We can see in the console that it skips 1 on 2 values. If we change the consumer rate to less than 100ms, all values are output.
Thanks for your feedback, as this behaviour (keeping track of the queue) could be useful for logs or just to be sure we don't miss any communication.
By the way, the package is awesome and I use it all the time ! Thanks for all the work done !!