I love SignalR and currently doing a few apps in it. Since SignalR is async if a logic error occurs on the service what is the best practice to handle that error?
I have been doing invoke to the client with an error object and adding it to a Reactive Extension observable, but that seems a little awkward.
The client is .Net Core and Blazor.
Suggestions?
SignalR is async if a logic error occurs on the service what is the best practice to handle that error?
ASP.NET Core SignalR provides built-in diagnostics logging feature that could help capture and log useful transports and Hub related information, which could help troubleshoot the issue.
Besides, from this doc, we can find:
Exceptions often contain sensitive information, such as connection information. Because of this, SignalR does not expose the details of exceptions that occur on the server to the client. However, instances of HubExceptionare sent to the client.
If you'd like to handle logic error occurs in Hub method, you can try to wrap the code logic in a try-catch block, then manually write exception in log.
Or you can create a new HubException instance with specified error message, which would be detected by client invoking this hub method.
try
{
//code logic here
//...
//...
//Convert.ToDateTime("hello");
await Clients.All.SendAsync("ReceiveMessage", user, message);
}
catch (Exception ex)
{
throw new HubException(ex.Message);
}
Related
I have recently used Mailkit lib in our project in order replacing .NET SmtpClient.
We have 2 business cases to use the SmtpClient to send emails.
In one instance we use SmtpClient to send queued emails in a separate process and other instance we send emails instantly.
While implementing I noticed that we have to call the Disconnect method of the Client instance.
mailClient.Disconnect(...);
It was not sure and not clear in the documentation what is the best way to call this method.
So my question, What is the best practice to use this method?
Call mailClient.Disconnect(true) per every message or mailClient.Disconnect(false)?
Out of interest, if I use the client within a using block, should I require to call Disconnect(...) explicitly after sending a message? I reckon it calls disconnect implicitly when the Dispose() gets executed.
using (var mailClient = new SmtpClient())
{
mailClient.Connect(...);
mailClient.AuthenticationMechanisms.Remove("XOAUTH2");
mailClient.Authenticate(...);
mailClient.Send(message);
mailClient.Disconnect(false);
}
Appreciate your feedback in this regard.
The Dispose() method will only close the socket connection if it is still alive (which is effectively the same as calling Disconnect (false)).
Calling Disconnect (true) is much more courteous, though, as it sends the appropriate LOGOUT or QUIT command to the server which allows the server to properly dispose of their resources.
I would like to have your suggestions on this.
I am new to ActiveVOS BPEL, please don't mind if my question seems dumb to you!
When we pass the data through SOAP UI, in ActiveVOS Designer upon removing the fault handler and change]ing the PDD Option "Suspend on uncaught Fault" to "true" for the BPEL process, I'm able to suspend and resume the process in the activeVOS Admin console.
Although, whenever I send the data through SOAP UI, it is giving me the time out exception without any response, but I could see the instance created in the Console.
When a request is sent through the SOAP UI, if we add FaultHandler to the BPEL process, the process directly ends up with the completed state. The options to resume the suspeneded process are disabled. Instead, I would like to resume the suspended process as well as response from the SOAP UI. Please address this and help me to achieve the intended result.
Thanks in advance!
the only thing that you can do is to place a scope (BPMN subprocess) and placing all activities from the initial receive (message catch event) to the initial reply (message throw event) in it. Then you can place an catch all fault handler in this scope. This will catch all errors that you want to suspend the process. Place a reply (message throw event) and a suspend after it in the fault handler. The reply will take care that the process caller will get some meaningful response and the ActiveVOS-specific suspend activity will then suspend the process. You can then rewind it or repair it by any means available in the ActiveVOS Console as long as you have a high enough persistence level configured in your PDD/server.
I am thinking about using Dart for server side programming. Because are no full frameworks similar to Ruby on Rails, I am reviewing lower level libraries. The most needed library is Posgresql driver. I found few and most mature seems to be https://pub.dartlang.org/packages/postgresql
And here is my problem. The Postgresql driver has async API. I know that async APIs are required for client side, simply to not block UI thread. However on server side threads are available so why Postgresql driver has async API?
I known about Promises APIs but for me this is just unneeded complexity when doing things on server side. Code readability is most important.
I just wonder if there is something in Dart language design that forces people to build async APIs. So the question is: can Dart have sync APIs for database and file IO operations?
Dart libraries/packages can offer sync APIs. DB ones don't tend to, because you usually don't want to block the entire server waiting for a potentially long DB operation to finish. For example, say you're creating a web server, with a request handler that fetches data from the DB and serves it. If you're only using sync operations, and you get 10 requests, 9 of those will be waiting for the first one to finish before being processed.
If your only concern is readability, you can wait for the await keyword to be implemented, which will help your code feel like sync code, while actually working async:
var conn = await connect(uri);
var results = await conn.query('select * from users').toList();
for(result in results) {
print("${result.username} has email address ${result.emailAddress}.");
}
Dart does have synchronous file io operations. For example see File.readAsStringSync().
Dart does not have a built in way to perform blocking io on a socket, which means that the postgresql library must be asynchronous.
Dart, even on the server, doesn't really have "threads". It has isolates which can run in parallel, but can only communicate by message passing, and do not have synchronisation primitives like mutexes.
Here is a list of server frameworks.
When writing asynchronous code in Dart, the Future.then() syntax, especially with multiple levels of nesting, can become tedious. Luckily the async/await feature is being implemented which means you can write code that is asynchronous but reads similar to code written with blocking io. For example:
main() async {
var conn = await connect('postgresql://foo');
try {
var sql = "select 'foo'";
var result = await conn.query(sql).toList();
return result[0];
} on Exception catch (ex) {
print('Query error: $ex');
} finally {
conn.close();
}
}
As of Nov14, to use async await you need to run dart with the --enable_async flag, and be prepared for crashes, and missing stack trace information - this feature is under active development and not yet stable. Another more stable option is to use the async_await package to translate your async/await code to use Futures.
If you have any specific questions about the postgresql driver (I am the author), feel free to open an issue against it in github, or to send me an email. My email address is on the postgresql pub page.
You need concurrent programming on the server too, not only on the client. It would be highly inefficient for the server to process requests from clients one after another - waiting until one request is totally completed before starting to process the next request while the Dart server process itself is waiting for the operating system, the database or the network to complete calls made to it.
When an I/O operation which are usually async is called, Dart can start processing other requests while it waits for invoked I/O operations to complete.
You can improve concurrent programming by using isolates but you can't create a Dart application that does some kind of I/O calls with sync calls only.
Dart doesn't support multithreading, if not in the form of Dart isolates (but those are not production ready). Only asynchronous processing is well supported, and the "await" keyword (the best syntax for coroutines) is being added to Dart in the next few months. If you need to build a small web site it will work great.
But if you need a really scalable solution for a big web site or a demanding web app, I suggest you to use the combination of Dart+Go. Make Dart to manage the client/UI side, and Golang to manage the data providers on server side. Go is the most performant language server side thanks to his innovative "Goroutines". Goroutines are a form or coroutines that runs automatically in multiple threads, combining the flexibility of asynchronous processing with the efficiency of synchronous multithreading. Goroutines are automatically multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.
Go+Dart makes a really powerful combination.
That is "After and only After" an Exception since I've been told to get it up front is a performance hit we don't want because that would be for each and every call rather than just for an Exception. Makes sense of course but I sure don't see how it can be done AFTER an Exception.
Use case goes like this: Some guys, perhaps bad guys, send us some bad SOAP and the dispatcher chucks out a SaajSoapEnvelopeException. How do I handle this gracefully?
So far what I have is an extension of MessageDispatcherServlet with an override of the doService() method. The web.xml file has been updated to show this Dispatcher for Spring's config. Within this override, surround the call to the super method with a try/catch and you catch the Exception but the problem here is that the stream for the HttpServletRequest is already closed, so you can't get the SOAP from here, AFIK.
Another problem is that I can't get a marshaller to wire in here. I have Java faults generated from our WSDL I would like to use but I think there is a problem with wiring marshallers in a non-endpoint class. Perhaps something about the namespace? I probably need to read up on how these work.
Bottum line: Is it possible to get the SOAP after an Exception or is it possible to predict that there will be an Exception so that I can grab it up front? Also, how can I get a fault marshaller into this Dispatcher or will I have to BS up a text version of the fault?
I'm fairly new to Web Services and what I know so far is mostly CXF. So far, I'm not much impressed with Spring WS. They have a long ways to go yet, IMHO. The fact that I can't get my WSDL from the service due to a known bug having to do with XSD references in WSDL not getting properly renamed to match the bean, is particularly annoying.
Have you tried a EndpointExceptionResolver?
For instance, I have used one to catch and translate authentication exceptions.
You'll probably need an EndpointInterceptor as well to wrap the exception resolver.
Does anyone know if it is possible to write to the response stream in OpenRasta rather than returning an object as a response resource? Alternatively, am I able to implement an HTTP handler but still leverage OpenRasta's URL rewriting?
Thanks
Chris
You can always keep an http handler on the side to do specialized things, but that ties you to asp.net and will prevent your code from being portable on other hosts. If that's something you're ok with, any handler that's registered for a specific route will get executed before openrasta on asp.net.
that said, codecs are the ones writing to the response stream, so provided you have a custom IMediaTypeWriter you can write the resource instance on a stream whichever way you want.
Say for example that you returned an IEnumerable from your handler, as those get deferred executed, you can just start the enumeration of those in your custom codec without any problem.