What are the timeouts (read/write on the HTTP server on the ingress) & calls to RMQ

[xtreme-sameer-vohra]

This covers

• Broker Ingress
• Trigger Dispatcher Trigger's sink takes longer than X to respond (are there any timeouts on the dispatcher acting as a client? Lets ensure there is a defined timeout rather than no timeout - Reference) #671

[gab-satchi]

/assign

[gab-satchi]

Moving this out of MVP as ingress timeouts aren't currently part of the eventing spec. Will work on driving the change through core eventing before implementing here.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[embano1]

Just checked the code (please correct me if I'm wrong) so that anyone interested in this topic has a better understanding of the connection handling from the ingress to the RMQ Cluster (via amqp091-go).

Note Evaluation done on the following commit of this repo:

git rev-parse head
dfd65c5bec16c4758218b67fe2095f2055fdfdeb

It seems for establishing the initial net.Conn to RMQ, the amqp091-go defaults are used:

https://github.com/knative-sandbox/eventing-rabbitmq/blob/dfd65c5bec16c4758218b67fe2095f2055fdfdeb/vendor/github.com/rabbitmq/amqp091-go/connection.go#L25

The connection is periodically probed/checked via the Heartbeat interval, which also seems to be using the default:

https://github.com/knative-sandbox/eventing-rabbitmq/blob/dfd65c5bec16c4758218b67fe2095f2055fdfdeb/vendor/github.com/rabbitmq/amqp091-go/connection.go#L24

tl;dr: During network/server issues, those affect any publisher, i.e. ingress.

Another issue IMHO is a forever blocking (deadlocking?) event publishing call:

https://github.com/knative-sandbox/eventing-rabbitmq/blob/dfd65c5bec16c4758218b67fe2095f2055fdfdeb/cmd/ingress/main.go#L201

Recently, a PR was added to amqp091-go which allows passing a context.Context when publishing to avoid this scenario: rabbitmq/amqp091-go#96

Might be a good one to implement on pkg bump and using a sane context timeout. cc/ @gab-satchi @salaboy

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[knative-prow-robot]

This issue or pull request is stale because it has been open for 90 days with no activity.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close

/lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.