I am using a service bus relay and are receiving the following error
There is only one application connecting to the path, and for some reason the number of listeners has climbed to 25, but there is not 25 listeners.
During testing I am ending the program and likely not calling "close" on the end point, but I would have through that service bus would clean this up. At any point in time there would only be one active listener on the end-point/path
I am not aware of a way of removing these end points, is there a way of clearing old dead listeners from a service bus? This now means my service cannot run or connect, and I can't find a way to fix the issue.
ServiceBus Relay Info
System.ServiceModel.QuotaExceededException occurred
HResult=-2146233087
Message=MaximumListenersPerEndpoint:25. TrackingId:d79456b4-cf41-4d4e-aa0a-88ccc6b82417_G12,TimeStamp:6/11/2015 4:42:29 AM
Source=Microsoft.ServiceBus
StackTrace:
at Microsoft.ServiceBus.RelayedOnewayListener.RelayedOnewayAmqpListenerClient.AmqpRelayedConnection.Open(TimeSpan timeout)
at Microsoft.ServiceBus.RelayedOnewayListener.RelayedOnewayAmqpListenerClient.GetOrCreateConnection(Uri via, TimeSpan timeout)
at Microsoft.ServiceBus.RelayedOnewayListener.RelayedOnewayAmqpListenerClient.Connect(TimeSpan timeout)
at Microsoft.ServiceBus.RelayedOnewayTcpClient.EnsureConnected(TimeSpan timeout, Boolean isRetry)
at Microsoft.ServiceBus.RelayedOnewayTcpClient.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at Microsoft.ServiceBus.RelayedOnewayListener.OnOpen(TimeSpan timeout)..........................
If the endpoint is persistent, you can delete the endpoint and recreate it. I am not sure how long it will take for the listeners to become deregistered, but deleting the endpoint should automatically remove them.
Related
I have a balanced environment where there are 2 workflow application instances running.
This are called from a sharepoint farm which is also balanced with 2 front ends.
The workflow make use of persistance and both workflows are connected to the same persistence database.
We are receiving the following error and we think it could be related to the balanced environment. This is because we have tested the workflows thouroughly on a non-balanced environment and we never received this error.
System.ServiceModel.FaultException: Operation 'DoSumbit|{http://tempuri.org/}IMyContract' on service instance with identifier '92d66ac3-da5a-48fb-a88d-a82820471fb0' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceMo... 211969e8-8427-4c55-9cd5-6ed911cd22d7
11/29/2011 09:32:28.01* w3wp.exe (0x0DCC) 0x082C SharePoint Foundation Runtime tkau Unexpected ...del.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at ....
Any assistance would be greatly appreciated.
Regards,
Joseph
Normally you get this error for the reason in the message. The workflow instance is not in a state where it can process the requested message. Normally this means the workflow is busy, or more likely the workflow is just waiting for some other event and the Receive activity that is supposed to handle this event isn't active.
You can also into problems when one host receives a message for a workflow instance loaded by another host but in that case you normally get an exception indicating that the workflow instance is locked by another WSH and can't be loaded at the time.
We have a Silverlight 4.0 application that makes many calls to our WCF services. We have lots of users and mostly it’s fine, but one user is having a problem that seems to be confined to a particular asynchronous call on a single (Windows 7) machine. It is always reproducible, but only for that call from that machine. The WCF request is sent but then after a pause the Silverlight app throws this:
Message: [HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Stack Trace: at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at MyContractClientChannel.EndApplicationSave(IAsyncResult result)
at MyServiceContract.EndApplicationSave(IAsyncResult result)
at MyServiceContractClient.OnEndApplicationSave(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)
The initiating call looks like this:
using (new OperationContextScope((IContextChannel)Client.InnerChannel))
{
Client.ApplicationSaveAsync(request, callback);
}
Client.ApplicationSaveAsync is the usual auto-generated code that calls System.ServiceModel.ClientBase.InvokeAsync.
When we watch the conversation with WireShark we see the request packets being sent (this takes about two seconds) followed by a delay of about ten seconds. Then comes the weird part. On a machine that works we see the response packets come down from the server, but on the problem machine we see the client suddenly send an empty packet with the TCP FIN flag set (before any response is received). We can’t understand why it would do this. When we try Fiddler instead of WireShark, Fiddler reports “Session State: Aborted”, which looks like just another interpretation of the same underlying problem (that the client has unexpectedly pulled the plug on the connection).
We would greatly appreciate any suggestions as to why this might be happening or what we can do to investigate it further.
The problem seemed to go away when we created a new Windows profile for the user.
I am getting a "The message could not be processed..." error from a WCF client. Please help, it's killing me.
I have a test win app that goes through a for loop to kick of x number of asynchronous calls. Each asynchronous call instantiates its own instance of a WCF proxy and calls a WCF service using that proxy. If x is about 35 or less, all is well. If x > 40 or so, many of the calls complete just fine, but a handful return this:
System.ServiceModel.Security.MessageSecurityException:
An unsecured or incorrectly secured fault was received from the other party.
See the inner FaultException for the fault code and detail. --->
System.ServiceModel.FaultException: The message could not be processed.
This is most likely because the action 'http://tempuri.org/IMyService/MakeRequest'
is incorrect or because the message contains an invalid or expired
security context token or because there is a mismatch between bindings.
The security context token would be invalid if the service aborted
the channel due to inactivity. To prevent the service from aborting
idle sessions prematurely increase the Receive timeout on the
service endpoint's binding.
--- End of inner exception stack trace ---
Server stack trace:
at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.ProcessReply(Message reply, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at ...
I am using client-side and server-side certificates, with message security. I don't get why it runs OK only a certain number of times, then pukes. It also seems to throw the error on calls that are made closer to the end of the iteration. Also, this error occurs long before any of my timeouts would be reached, which are set on the client and server-side the same:
<binding name="WSHttpBinding_IMyService"
closeTimeout="00:10:00" openTimeout="00:10:00"
receiveTimeout="00:10:00" sendTimeout="00:10:00"... />
Additionally, I am using service throttling:
<serviceThrottling
maxConcurrentCalls="100"
maxConcurrentSessions="100" />
Any ideas?
Thanks, Mark.
You get the error when you reach a certain limit on the number of calls and each call creates it's own proxy.
The error is therefore probably related to the creation or the closing and clean up of the proxy.
You have not posted your code, but you may be able to solve then problem and improve the performance of your code by following these best practices: http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx
Another typical problem with async wcf calls is to make sure that the proxy is not closed before the async call returns.
I have a sample WCF project that reproduce a problem that I have with my real WCF application.
You can download the source code of my sample WCF application here
Accoding to the timeouts sets in the code and config files, I don't understand what is appening :
**** Server exception : System.ServiceModel.CommunicationObjectAbortedException:
The communication object, System.ServiceModel.Security.SecuritySessionServerSettings+SecurityReplySessionChannel, cannot be used for communication because it
has been Aborted.
at System.ServiceModel.Channels.CommunicationObject.ThrowIfClosedOrNotOpen()
at System.ServiceModel.Security.SecuritySessionServerSettings.ServerSecuritySessionChannel.SecureApplicationMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
at System.ServiceModel.Security.SecuritySessionServerSettings.SecuritySessionRequestContext.OnReply(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.RequestContextBase.Reply(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.RequestContextBase.Reply(Message message)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.Reply(MessageRpc& rpc)
**** client exception : : System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: The message could not be processed. This is most likely because the action 'http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
--- End of inner exception stack trace ---
Server stack trace:
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.ProcessRequestContext(RequestContext requestContext, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.ReceiveInternal(TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.CloseOutputSession(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.CloseSession(TimeSpan timeout, Boolean& wasAborted)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnClose(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnClose(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.Close()
at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose()
at WindowsFormsApplication1.Program.Main() in C:\Users\sdoucet\Documents\Visual Studio 2008\Projects\TestWCFLongExecution\WindowsFormsApplication1\Program.cs:line 25
We had a similar issue because the application pool hosting the service was configured to have Maximum Worker Processes greater than 1. For a call to Abort or Close to succeed, it needs to be routed to the same service instance that handled the original request.
Looks like you are passing exceptions back to the client. WCF doesn't like regular exceptions, it wants fauls or a FaultException in case of errors. After and exception has been returned the channel is in a faulted state and cannot be used again. After a FaultException the channel is still usable.
I had a similar issue where I made a wcf service async call. After receiving the result in the async_completed method I got an exception.
"An exception occurred during the operation, making the result invalid. Check InnerException for exception"
InnerException:
"The communication object cannot be used for communication because it has been Aborted"
After a lot of effort I find the solution, just catch the exception without throwing in the async_completed method. (i.e. implemented the try/catch). I didn't understand what is the exact problem, but somehow communication channel is breaking.
I tried the above approch from the following link
http://geekswithblogs.net/SoftwareDoneRight/archive/2008/05/23/clean-up-wcf-clients--the-right-way.aspx
Still I am not confident that this is the right approach, but as per my scenario with the operation result I am not doing anything furtherly. So it is catching exception and stopping the service.
We have to connect to a third party SOAP service and we are using WCF to do so. The service was developed using Apache AXIS, and we have no control over it, and have no influence to change how it works.
The problem we are seeing is that it expects the requests to be formatted using Web Services Security, so we are doing all the correct signing, etc. The response from the 3rd party however, is not secured. If we sniff the wire, we see the response coming back fine (albeit without any timestamp, signature etc.).
The underlying .NET components throw this as an error because it sees it as a security issue, so we don't actually receive the soap response as such. Is there any way to configure the WCF framework for sending secure requests, but not to expect security fields in the response? Looking at the OASIS specs, it doesn't appear to mandate that the responses must be secure.
For information, here's the exception we see:
The exception we receive is:
System.ServiceModel.Security.MessageSecurityException was caught
Message="Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This can occur if the service is configured for security and the client is not using security."
Source="mscorlib"
StackTrace:
Server stack trace:
at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessageCore(Message& message, TimeSpan timeout)
at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout)
at System.ServiceModel.Security.SecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
Incidentally, I've seen plenty of posts stating that if you leave the timestamp out, then the security fields will not be expected. This is not an option - The service we are communicating with mandates timestamps.
Microsoft has a hotfix for this functionality now.
http://support.microsoft.com/kb/971493
Funny you should ask this question. I asked Microsoft how to do this about a year ago. At the time, using .NET 3.0, it was not possible. Not sure if that changed in the 3.5 world. But, no, there was no physical way of adding security to the request and leaving the response empty.
At my previous employer we used a model that required a WS-Security header using certificates on the request but the response was left unsecured.
You can do this with ASMX web services and WSE, but not with WCF v3.0.
There is a good chance you will not be able to get away with configuration alone. I had to do some integration work with Axxis (our end was WSE3 -- WCF's ancestor), and I had to write some code and stick it into WSE3's pipeline to massage the response from Axxis before passing it over to WSE3. The good news is that adding these handlers to the pipeline is fairly straightforward, and once in the handler, you just get an instance of a SoapMessage, and can do anything you want with it (like removing the timestamp, for example)