I want to execute database operation in a handler and then send three commands to other handlers.
I want to make sure that all the execution of database operation together with sending commands occur in a transaction and whether all succeed or all fail.
I am using .net core and when I try to do this I get an exception that "This platform does not support distributed Transactions"
I was using RabbitMQ Transport and then SQL server transport but still getting the same problem.
I would like to know the best way to ensure that all the execution is ATOMIC under .NET Core and RabbitMQ or SQL Server transport.
Thanks
I am surprised that you get this particular exception, because Rebus does not participate in distributed transactions (at least not with any of the supported transports, and especially not with RabbitMQ).
Could you maybe update your question to include the full exception details (with stack trace and everything)? And maybe tell a little bit about how you're performing your database operations?
Related
I am using spring-kafka latest version and using #KafkaListener. I am using BatchListener. In the method that is listening to the list of messages i want to call the acknowledge only if the batch of records are processed. But the spring framework is not sending those messages again until I restart the application. So I used stop() and start() methods on KafkaListenerEndpointRegistry if the records were not processed but I feel like its not a good way of solving the problem. Is there a better way of handling this.
See the documentation for the SeekToCurrentBatchErrorHandler.
The SeekToCurrentBatchErrorHandler seeks each partition to the first record in each partition in the batch so the whole batch is replayed. This error handler does not support recovery because the framework cannot know which message in the batch is failing.
Lets assume rebus could not publish message to rabbitmq or some other queue, what is the best practice to handle this exception.
I stopped rabbitmq service and rebus threw Aggregate exception. I can manually cacth this exception in try - catch block but is there a better solution to catch exceptions when such situations happened ?
First off: If you get an exception when initially sending/publishing a message (e.g. while handling a web request), there's nothing you can do, really. Sorry ;)
You should probably log - thoroughly - all the information you can, and then be sure to set up logging so that the information ends up in a file or in some other persistent log. And then you should have some kind of notification or a process in place that ensures that someone will at some point look at the log.
You should probably have this kind of logging in place, regardless of the type of work you do.
Depending on how important your information is, you could also set up some kind of retry mechanism (although you should be careful that you do not consume threads and too much memory while retrying). Also, since your web application should be able to be recycled at any time, you probably should not rely (too much) on retries.
You can do some things, though, in order to minimize the risk of ending up in a situation where you can't send/publish.
I can recommend that you use some kind of high-availability transport, like MSMQ (because it has local outgoing queues), RabbitMQ (with a shovel on each machine), or Azure Service Bus or Azure Storage Queues if you're in Azure.
Moreover - if you were using MSMQ, and you want to publish an event - I would recommend that you await bus.Send(theEvent) first, and then when you handle the message, you await bus.Publish(theEvent). This is because Rebus (with the MSMQ transport) needs to do a lookup in the subscription storage in order to get all subscribers for the given event. This is not a problem with RabbitMQ though, because Rebus will use Rabbit's topics to do pub/sub and will be just as safe as doing an ordinary send.
When you're sending/publishing from within a Rebus message handler, there is of course no problem, since the receive operation will be rolled back, and eventually the incoming message will end up in an error queue.
I hope that cast some light on the situation :)
I would like to use Rebus for integration with third-party application by adding triggers to that application's database so the triggers would insert records in format of Rebus message containing information about changes in database (operation type: insert, update, delete, table name and row id). Tell me please is there some way to do this easily or I would need to create stored procedure myself by looking into https://github.com/rebus-org/Rebus/blob/master/src/Rebus/Transports/Sql/SqlServerMessageQueue.cs Send method?
Alternatively I could just fire the exe with parameters from the trigger but it is not transactional.
Also I've seen this issue https://github.com/rebus-org/Rebus/issues/119 but I guess it's dead idea.
Maybe there is other recommended approach?
Update: I just realized body of Rebus message is serialized so it would be insane to do that in SQL (and even not possible without SQL-CLR) so maybe the only way would be to create custom transport with ReceiveMessage method accepting messages in my own format?
Thanks in advance :)
I've had excellent results integrating with "stuff happening in SQL Server" by using SQL Server Service Broker - not directly (i.e. as a Rebus transport implementation), but as a message queue that I could poll from the outside.
Whenever something interesting happened in the database, a trigger would query some tables and select the result set out for xml auto into an XML message that would be sent to a service broker queue.
I then had a Rebus endpoint with a System.Timers.Timer that would poll the broker queue and bus.SendLocal the received XML as a string - this way, everything from parsing the XML and on would be based on Rebus messages, retries, and error queues, and the customary reliability that follows :)
Is there any error logging option in APIGee?
I am enabling a proxy endpoint in APIGee for a customer. If there is any error in the flow, how can I log it to a persistent store?
Specifically, I am using javascript policies and parsing some of the returned by back-end service, format to a different format. If there is any parsing error, where and how can I log it?
I am able to catch the error with try catch block.
Can I send an email in the catch block to a specific email address?
Thanks,
Deepak
You can catch the error in your catch block and then set the appropriate variable to contain the detailed error message you might have ran into.You can use syslog/messagelogging policy to send all the request details along with any parsing exception that you might have. You need some kind of a logging server at your end to be sent the logs to or you could also use public log management services, such as loggly. Refer to this section for more details - http://apigee.com/docs/api-services/content/log-messages-using-messagelogging
Vineet I think you are looking to solve the following problems here:
During the coding process you want to debug and understand what is going on? Something that lets you log.debug equivalent.
You want to also trigger exception flows or external processes when things go wrong in your proxy flow.
For #1 you can assign variables and trace using apigee's debug view. Any flow variable assignment in Apigee policies is printed in the debug view, if the policy is executed. So that provides you with log.debug mechanism, whenever you trace.
For #2 you can take a variety of approaches based on rest of your systems and processes. The previous answer by #Mike Dunker is a good approach. I can suggest a few more alternates
As an alternate you can also use Apigee's analytics views to monitor errors, albeit after the fact.
You can set up external monitoring scripts on your backend or on the apigee endpoint based on some synthetic transaction that touches upon the entire logic of your flow. When the services return error you can measure metrics and/or raise alert from your monitoring system.
If you have an on-premise installation of Apigee, you may want to consume apigee log files on the servers and raise appropriate actions on errors.
You can raise a desired error message to a JMS queue when error happens. Refer to Apigee's JMS support here
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.