I'm on Masstransit 6.2.
I'm using Marten for saga storage and serilog for logging.
My saga often gets database concurrency exceptions but can be recovered using retry/re-delivery.
However these exceptions are logged as "SAGA:" errors along with the "R-RETRY" warnings.
I found this old issue https://github.com/MassTransit/MassTransit/issues/626, apparently this has been addressed? Is there anything can be done to downgrade these errors or stop logging them?
Confirmed this is fixed in 6.2.2.
Related
In my Quarkus app I get Enlisted connection used without active transaction errors around once a day (on a public API used quite a lot).
It seems to come from Agroal (here https://github.com/agroal/agroal/blob/master/agroal-pool/src/main/java/io/agroal/pool/ConnectionHandler.java#L393).
According to the stack trace it fails at various places in REST endpoints annotated with #Transactional.
In PostgreSQL I only get the following:
ERROR: canceling statement due to user request
I worked around this issue by firing an event which is listened in a TransactionPhase.AFTER_SUCCESS method (and this method send the Kafka message).
I have a sink application that fails to write to db, but am having trouble debugging. Note that I also asked a more specific question here, but this question in SO is more general: How should I go about debuggging an SCDF stream pipeline when no errors come up?
What I'm trying to do
I am trying to follow a tutorial (specifically, this tutorial) which uses some prebuilt applications. Everything is up and running with no error messages, and the source application is correctly writing to Kafka. However, the sink seems to be failing to write anything.
Note that I do see the debugging guide here:
https://dataflow.spring.io/docs/stream-developer-guides/troubleshooting/debugging-stream-apps/#sinks
However, this seems to only be relevant when you are writing your own sink.
I am not asking about how to solve my issue per se, but rather about debugging protocol for SCDF apps in general. What is the best way to go about debugging in these kinds of situations where no errors come up but the core functionality isn't working?
Assuming you know how to view the logs and there are no error messages, the next step is to turn on DEBUG logging for spring-integration. You can set a property on the sink logging.level.org.springframework.integration=DEBUG that will log any messages coming into the sink.
Upgrading to MassTransit 4.x, overtop RabbitMQ. My application configuration was using PublisherConfirmation set to true, to ensure message delivery without the overhead of transactions. (In least, that was what the docs used to say.)
In MT 4.x., it appears that PublisherConfirmation no longer exists.
I haven't found any info (yet) on why this went away, or what replaces it moving forward. Essentially, I don't want fire-and-forget; if the message doesn't reach the queue I want an exception.
Any guidance would be appreciated.
To configure PublisherConfirmation using MT 4.x or later, that option is now configured on the host, instead of the bus.
https://github.com/MassTransit/MassTransit/blob/develop/src/MassTransit.RabbitMqTransport/Configuration/IRabbitMqHostConfigurator.cs#L24
I cannot understand why sometimes my spring boot (version 1.4.1) application based on spring-boot-starter-tomcat and spring-boot-starter-websocket stops working.
Specifically my application provides is meant to provide to the client some real-time events about system status. These events can be both periodical or in response to user input and events are sent by means of the SimpMessagingTemplate's convertAndSend method.
Sometimes all events stops working but I cannot find any evidence in logs: nor exceptions neither BrokerAvailabilityEvents saying that the Broker failed.
I have no idea of how to fix it.
It turned out that SimpMessagingTemplate's convertAndSend method was not called because the thread that was responsible for calling it on behalf of an event was stuck and froze all event notification chain.
For an unknown reason, MassTransit keeps moving messages of a specific type to the error queue. I believe that a deserialization error is causing this.
What's the best way to debug deserialization errors?
The easiest way to figure out what's going on is enable one of the logging providers and look at the logs for a given consumer that's kicking stuff over. You might need to configure specific loggers, anything under MassTransit would be helpful.
In addition, I believe Chris added the some information to the envelop in a recent version of MT. You might be able to identify the error just by looking at the JSON or XML payload envelop in the message queue.