daniel-k commented on pull request #15157:
URL: https://github.com/apache/beam/pull/15157#issuecomment-883961751
Thank you so much for taking care of this longstanding bug! However, I'm
still seeing these errors when deployed to DataFlow and I believe there's still
a conceptual problem with persisting the session IDs in the checkpoint mark.
The channel is `transient` because it cannot be serialized, however the session
ID list is not, i.e. it will be serialized. But, a session ID is only valid in
the scope of the channel from which the message had been received, so I believe
it doesn't make sense to persist the session IDs in the checkpoint mark.
I'm really wondering how anyone could have been able to use
`RabbitMqIO.Read` in the past :thinking:
These are the changes I locally made on top of your PR:
```diff
Instant latestTimestamp = Instant.now();
- final ConcurrentLinkedQueue<Long> sessionIds = new
ConcurrentLinkedQueue<>();
+ transient ConcurrentLinkedQueue<Long> sessionIds = new
ConcurrentLinkedQueue<>();
+
+ // this method is called after deserialization on the deserialized
object
+ private Object readResolve() {
+ // (re-)initialize transient fields as required
+ this.sessionIds = new ConcurrentLinkedQueue<>();
+ return this;
+ }
```
The code is running fine for 16h on DataFlow now. I tried force closing a
connection from the RabbitMQ web interface and the pipeline has recovered
immediately (of course you'll get `com.rabbitmq.client.AlreadyClosedException:
connection is already closed due to connection error; protocol method:
#method<connection.close>(reply-code=320, reply-text=CONNECTION_FORCED - Closed
via management plugin, class-id=0, method-id=0)` but that's expected).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
