Conversation
|
Probably should set a |
|
It doesn't fail for me, trying the example from the README $ cat examples/readme.js
import { AMQPClient } from '../lib/mjs/amqp-client.js'
async function run() {
try {
const amqp = new AMQPClient("amqp://localhost:15672?hearbeat=1")
const conn = await amqp.connect()
const ch = await conn.channel()
const q = await ch.queue()
const consumer = await q.subscribe({noAck: true}, async (msg) => {
console.log(msg.bodyToString())
await consumer.cancel()
})
await q.publish("Hello World", {deliveryMode: 2})
await consumer.wait() // will block until consumer is canceled or throw an error if server closed channel/connection
await conn.close()
} catch (e) {
console.error("ERROR", e)
e.connection.close()
setTimeout(run, 1000) // will try to reconnect in 1s
}
}
run()(I checked out this branch and ran |
|
(if I stop RabbitMQ it fails with |
Oops typo in the URI, if I fix it ( |
|
Is it only when using |
|
Without heartbeat it will wait 60s for successful connection, with heartbeat=1, only 1 second. Could lower it, but sometimes an overloaded RabbitMQ server might take a long time to authenticate to. |
|
The example program exit without error after ~5 seconds when not using the heartbeat parameter, is that expected or should it error too? when trying to connect to the mgmt HTTP port |
|
That's probably because the server closes the TCP connection after 5s when
it hasnt seen a valid HTTP request. I think if the example code had a
try/catch block the catch block would get the error, but now the run
function just returns early without and error... I think...
…On Thu, 27 Jul 2023, 08:06 Patrik Ragnarsson, ***@***.***> wrote:
The example program exit without error after ~5 seconds when not using the
heartbeat parameter, is that expected or should it error too? when trying
to connect to the mgmt HTTP port
—
Reply to this email directly, view it on GitHub
<#78 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABL6TRKW7ISEFZXBN7NLLDXSIAMTANCNFSM6AAAAAA2X44RNQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The example program do have try/catch, and if I run it with it does error after the timeout (which I lowered to 10 seconds when testing) (full log here) but if I run the example program against Puma (Ruby web server) it returns directly without any error |
|
Using main branch against the Python web server, it seems to hang forever (no bad request response logged), so things have improved with this change (against Puma, main and this branch behaves the same). |
|
Let's merge this, it is an improvement for sure. |
2 participants
Fixes #60