I have fully working duplex messaging solution for Silverlight application. Now I would like to add one feature to it. When user leaves the application I want to notify the server about that by sending the last message before exit.
I have tried to send duplex message during Application Exit event, but DuplexServiceClient is already in CommunicationState.Faulted state.
I've also tried to establish new connection and send the message. Everything seemed to be okay on the client side, but no message has been send at all. I checked that twice by using Fiddler.
App.Current.Exit += (s, e) =>
{
var dsc = new DuplexServiceClient(_binding, new EndpointAddress("../Services/MyService.svc"));
dsc.SendToServiceAsync(new UserLeave());
};
Crucial thing is, that I need to notify the server immediately after user leaves the application, so timeouts or similar workarounds are not good enough for me in this situation.
Does anybody have a working solution?
I found similar topic here in SO. Aliostad's answer made me think about this once more. You can never be sure you will get the signal from client that he's leaving. So I ended up with timeout solution.
Related
For some reason the emails are taking around 8 seconds to send, and it makes the website feel like nothing is happening.
client.Send(message);
client.Disconnect(true);
I am wondering if SendAsync would fix the issue, but would the following code cause any issues in the future:
client.SendAsync(message);
client.Disconnect(true);
I feel like the client could attempt to disconnect before the email is fully sent since the program won't wait for SendAsync.
Is there a better way to do this? I couldn't find an example in the documentation.
You would need to await the SendAsync() or you could end up disconnecting before the message has been sent.
That said, asynchronous methods, depending on how your application is designed, could be the right solution to making your app not "hang".
I have a process whereby an admin must be alerted and the message automatically retried if some business logic is not meet.
Currently what I did is I throw and Exception to force NServiceBus to retry the message.
I have a feeling this is not what I am supposed to do. Is this the proper way of doing it?
public void Handle(ImportantCmd message)
{
//do some awesome business logic here
..a business logic is not meet..
//send email alert in case of error
Bus.Publish<SendEmailCmd>(email =>
{
email.To = "pooradmin#awesomecompany.com";
email.Title = "Important title";
email.Body = "Important message";
});
//then force NServiceBus to retry
throw new Exception("Blah blah...., retrying this message.");
}
Update: I would like an admin to be alerted whenever some condition is not met and he/she should be able to see all messages that are affected (perhaps in a dedicated queue?) and possibly retry them.
Basically our service depends on an external service. This external service occasionally could return erroneous respond (but if we retry it might work). That is why I am alerting the admin and at the same time retrying them.
Given your update (i'm assuming the admin will not alter the message) i would say you can use the FLR (First Level retry) and SLR(Second Level Retry) to retry the messages as the web service you are calling will eventually be able to process your message.
If that fails, the message will end up in the error queue.
You can monitor the error queue, by polling ServiceControl using it's API (if you use the platform installer it will install ServiceControl with NServiceBus) or subscribing to the MessageFailed event ServiceControl is publishing like this spike code more on David's blog .
Here is a link about SLR
Check Out David's book
The retry mechanism of NServiceBus (driven by throwing an exception) is supposed to be for infrastructure problems (deadlocks, servers unavailable, outright bugs, etc.) that a developer would need to look at. That way transient failures (deadlocks, web service down) is taken care of on an automatic retry, and permanent errors (whoops looks like I divided by zero!) go to an error queue for a developer to figure out and take administrative action.
Now, if your endpoint is transactional, your code above will not work as expected because either everything in the message handler is in the transaction. That means if you throw an exception, your Bus.Publish (or Bus.Send, and you can't/shouldn't publish a command) will not actually happen.
Really, I don't understand what sort of business logic would require an alert and a retry. Can you elaborate? What is it that makes your business logic so non-deterministic based on the incoming message? And can anything be done about that?
But at the end of the day, this business logic sounds like it's part of a business process, which should stay expressed in messages, not in errors and retry. So if a condition means you need to notify someone and so something else, publish a ThingHappened event (a subscriber can send an email) and then have another handler do whatever is necessary to handle that business process. If that means that, in the future, a new command comes through with largely the same data, then so be it.
I have a producer sending durable messages to a RabbitMQ exchange. If the RabbitMQ memory or disk exceeds the watermark threshold, RabbitMQ will block my producer. The documentation says that it stops reading from the socket, and also pauses heartbeats.
What I would like is a way to know in my producer code that I have been blocked. Currently, even with a heartbeat enabled, everything just pauses forever. I'd like to receive some sort of exception so that I know I've been blocked and I can warn the user and/or take some other action, but I can't find any way to do this. I am using both the Java and C# clients and would need this functionality in both. Any advice? Thanks.
Sorry to tell you but with RabbitMQ (at least with 2.8.6) this isn't possible :-(
had a similar problem, which centred around trying to establish a channel when the connection was blocked. The result was the same as what you're experiencing.
I did some investigation into the actual core of the RabbitMQ C# .Net Library and discovered the root cause of the problem is that it goes into an infinite blocking state.
You can see more details on the RabbitMQ mailing list here:
http://rabbitmq.1065348.n5.nabble.com/Net-Client-locks-trying-to-create-a-channel-on-a-blocked-connection-td21588.html
One suggestion (which we didn't implement) was to do the work inside of a thread and have some other component manage the timeout and kill the thread if it is exceeded. We just accepted the risk :-(
The Rabbitmq uses a blocking rpc call that listens for a reply indefinitely.
If you look the Java client api, what it does is:
AMQChannel.BlockingRpcContinuation k = new AMQChannel.SimpleBlockingRpcContinuation();
k.getReply(-1);
Now -1 passed in the argument blocks until a reply is received.
The good thing is you could pass in your timeout in order to make it return.
The bad thing is you will have to update the client jars.
If you are OK with doing that, you could pass in a timeout wherever a blocking call like above is made.
The code would look something like:
try {
return k.getReply(200);
} catch (TimeoutException e) {
throw new MyCustomRuntimeorTimeoutException("RabbitTimeout ex",e);
}
And in your code you could handle this exception and perform your logic in this event.
Some related classes that might require this fix would be:
com.rabbitmq.client.impl.AMQChannel
com.rabbitmq.client.impl.ChannelN
com.rabbitmq.client.impl.AMQConnection
FYI: I have tried this and it works.
I have a WCF self-hosted service with a net.tcp DuplexChannel. On the server I run the following to disconnect a client:
((ICommunicationObject)client.CallbackChannel).Close();
This works fine but how do I detect on the client that it has been disconnected?
Ive hooked up to Closed and Faulted-events on both the InstanceContext of the callback and the channel to the server:
InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);
and
((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);
But nothing works. I never get notified. The workaround Im using now is to have a method in the callback that triggers a disconnect from the client-side instead. But I rather not do it this way. I especially dont want to let the server wait for a user to disconnect.
EDIT
I just realized that when disconnecting from client-side I run a method in the service-contract which is marked with IsTerminating = true:
[OperationContract(IsTerminating = true)]
void Disconnect();
I figured it would be the same on the callback-contract then? I tried adding the same method to my callback and it did terminate the callback-channel from the server point of view but I still didnt got notified on the client-side...weird
EDIT
I found out some more info about this:
When the server aborts the callback
channel, a fault travels back to the
client, the client faults and we get
the Faulted event on the client.
When the server closes the callback
channel, the session is still open
until the client issues the close.
Once the client closes the channel
you'll see the Closed event.
According to this statement the Close-event is not triggered mearly by closing the callbackchannel from the server, the client has to close it as well. So I could run Close on the client in the terminating Disconnect-method of the callback. Or I could use the Abort-method on the callback server-side and skip using a Disconnect-method on the callback. I dont know which one I preffer honestly. Hmmmm.
EDIT
I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext. Nice.
I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext.
You can simply do a callback just before closing the callback channel telling the client you're closing the channel.
So just before this line of code:
((ICommunicationObject)client.CallbackChannel).Close();
I'm having a problem where the WCF service hangs after 13-14 asynchronous process calls from the client. This occurs all the time. The client is a mobile JavaFX app. There is no specific error outputted in the server as well as in client. Someone suggested that it might be a throttling issue.
I've set the service side .config parameters maxConcurrent calls from 10 to 500
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500” />
So this means, it should be able to accept more than 10 calls, right? However, it didn't resolve this issue. Still hangs on the 13-14th process call.
Only one client is connecting to this web service.
What do you think is wrong?
Do you close the client after doing your call?
When I encountered this problem, I did not close it, and the open requests blocked the service after a short time.
Edit: Ok, I know nothing about JavaFX =) The code below is C#, sorry. But you can surely do something similar.
Use either
WcfClient client = new WcfClient()
// ...
client.Close()
or
using(WcfClient client = new WcfClient()){
// ...
}
Similar problem here - I have an app calling from one process to another, locally, named pipes.
Calls are really light in code- basically takex an array of serializable objects, queues them on other side. Occasionally it hangs. Restarts afte rtimeout. no data lost, but... as the data is financial data, and the receiving app an autoamted trading system, that may result in very bad financial issues. Not been able to reproduce it yet.
This could very easily be caused by any deadlock condition in your code. If your service locks up and starts eating up 100% or CPU you have a dead lock. Create a dump file and see where your code was at.
I ran into the same issue my first WCF app it was a dictionary that i wasn't making sure was synchronized in logging code.
The SvcTraceViewer is super helpful in figuring out tough wcf