I am using the netMsmqBinding with a transactional queue, and although the WCF service is called without problems, the service is throwing a MsmqException just 60 seconds after the message is processed.
This is the exception:
System.ServiceModel.MsmqException (0xC00E0051): An error occurred while receiving a message from the queue: Unrecognized error
-1072824239 (0xc00e0051). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from. at
System.ServiceModel.Channels.MsmqInputChannelBase.TryReceive(TimeSpan
timeout, Message& message) at
System.ServiceModel.Dispatcher.InputChannelBinder.TryReceive(TimeSpan
timeout, RequestContext& requestContext) at
System.ServiceModel.Dispatcher.ErrorHandlingReceiver.TryReceive(TimeSpan
timeout, RequestContext& requestContext)
I have done some research, debugging and tracing and I have found that when a new message is received, two transactions are opened, the first one is committed just after the service execution, but the second one is never committed, so then, after 60 seconds, the DTC aborts it throwing the MsmqException.
This is the operation definition:
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void SomeOperation(SomeParameter parameter)
{
// business logic
}
Any ideas about what is happening, and how can I solve this issue?
UPDATE:
Config:
<netMsmqBinding>
<binding name="TransactionalMsmqBinding" exactlyOnce="true" deadLetterQueue="System" receiveErrorHandling="Move">
<security mode="None"/>
</binding>
</netMsmqBinding>
...
<service name="SomeNamespace.SomeService">
<endpoint contract="SomeNamespace.ISomeService" bindingConfiguration="TransactionalMsmqBinding" binding="netMsmqBinding" address="net.msmq://localhost/private/services/someservice.svc">
</endpoint>
<endpoint contract="SomeNamespace.IAnotherService" bindingConfiguration="TransactionalMsmqBinding" binding="netMsmqBinding" address="net.msmq://localhost/private/services/anotherservice.svc">
</endpoint>
</service>
Service Implementation:
[ExceptionShieldingBehavior(typeof(ArgumentValidationException), typeof(ValidationServiceException))]
[AuthorizationAndAuditBehaviour]
[ServiceBehavior(Namespace = GlobalConstants.ServiceContractNamespace)]
public class SomeService: ISomeService, IAnotherService
{
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void SomeOperation(SomeParameter parameter)
{
// business logic
}
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void AnotherOperation(AnotherParameter parameter)
{
// business logic
}
}
Service Contracts:
[ServiceContract(Namespace = GlobalConstants.ServiceContractNamespace)]
public interface ISomeService
{
[OperationContract(IsOneWay = true)]
void SomeOperation(SomeParameter parameter);
}
[ServiceContract(Namespace = GlobalConstants.ServiceContractNamespace)]
public interface IAnotherService
{
[OperationContract(IsOneWay = true)]
void AnotherOperation(AnotherParameter parameter);
}
Complete behavior:
The client sends a message
The service is activated
The DTC starts two transactions (I can see them in the DTC monitor and in the TransactionManager.DistributedTransactionStarted event)
The first transaction finishes as soon as the operation finishes
The second transaction is aborted 60 seconds after (MsmqException is thrown)
The wcf host (IIS) is sometimes faulted (I have some code to automatically recover it, apparently this behaviour has changed in .net 4)
If the host was broken and automatically recovered, all will happen again on next message
If the host was not broken, the second transaction won't start the next time and everything will work without problems :).
If I recycle the AppPool, the problem starts again
I have found the problem.
As I am exposing the same Service using two different msmq Endpoints, for some weird reason the SMSvcHost.exe process activates the same Endpoint twice.
I have just written a post with the solution: http://blog.jorgef.net/2011/07/msmqexception.html
I hope it helps.
Jorge
Related
I am trying to design a WCF service that would listen to WSSB 1.1 queue. Pl find the service contract and config below.
[ServiceContract]
public interface IService
{
[OperationContract(IsOneWay = true, Action = "*")]
[ReceiveContextEnabled(ManualControl = true)]
void ReceiveDocument(System.ServiceModel.Channels.Message msg);
}
public class Service : IService
{
public void ReceiveDocument(System.ServiceModel.Channels.Message msg)
{
Trace.WriteLine("Message reached queue");
}
}
<services>
<service name="MyNameSpace.Service">
<endpoint name="DocumentReceived" address="sb://<mycomputername>/ServiceBusDefaultNamespace/queue" binding="netMessagingBinding" bindingConfiguration="messagingBinding" contract="MyNameSpace.IService" behaviorConfiguration="securityBehavior" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
After deployment, I am browsing the service wsdl manually to make sure it is warmed up. Still It is not working when I post a message to the WSSB queue. It should print diagnostics messages in Dbgview. Is there any issue with the above code ? Am I missing anything here ? Pl help.
It is probably not connecting to the SB. If it is being tested on a Windows 7 machine instead of Server machine, it can give issues with Token provider service (STS). Hence for testing in Windows 7, use Shared access signature instead of Windows STS uri. Add WCF tracing to the service for more information.
I'm writing a WCF service with some authentication and a custom error handler. However, I'm coming up against this problem: my implementation of IErrorHandler is not getting hit when the authentication throws an exception, but runs just fine with other exeptions.
Does authentication run before IErrorHandler gets built? Am I barking up the wrong tree trying to get it to catch those errors?
Yes, I have tried (and am) throwing a FaultException in my authentication, not SecurityTokenException.
So first thing is to make sure that your custom Error Handler is also implementing IServiceBehavior. IServiceBehavior requires that you implement a couple other methods but the important one is "ApplyDispatchBehavior", in which you must add the ErrorHandler to the channel dispatchers.
C#
public class CustomErrorHandler: IServiceBehavior, IErrorHandler
{
public bool HandleError(Exception error)
{
//Return True here if you want the service to continue on as if
// the error was handled
return true;
}
public void ProvideFault(Exception error,
MessageVersion version,
ref Message fault)
{
FaultException fe = new FaultException(
new FaultReason(error.Message),
new FaultCode("Service Error"));
MessageFault mf = fe.CreateMessageFault();
fault = Message.CreateMessage(version, mf, fe.Action);
}
public void ApplyDispatchBehavior(ServiceDescription serviceDescription,
ServiceHostBase serviceHostBase)
{
IErrorHandler eh = new CustomErrorHandler();
foreach (ChannelDsipatcherBase cdb in serviceHostBase.ChannelDispatchers)
{
ChannelDispatcher cd = cdb as ChannelDispatcher;
cd.ErrorHandlers.Add(eh);
}
}
public void AddBindingParameters(ServiceDescription serviceDescription,
ServiceHostBase serviceHostBase,
Collection<ServiceEndpoint> endpoints,
BindingParameterCollection bindingParameters)
{
//Add binding parameters if you want, I am not
}
public void Validate(ServiceDescription serviceDescription,
ServiceHostBase serviceHostBase)
{
//Add custom fault validation here if you want
}
}
Then you need to add the CustomErrorHandler as a service behavior and add the behavior
web.config
<system.serviceModel>
<extensions>
<behaviorExtensions>
<add name="ErrorHandler"
type="ServiceNamespace.CustomErrorHandler, ServiceNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</behaviorExtensions>
</extensions>
<behaviors>
<serviceBehaviors>
<behavior name="MyBehavior1">
<!--Put other behaviors for your service here then add the next line-->
<ErrorHandler />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
This way all your thrown exceptions will be converted to faults to return back to the client.
In the case of SecurityTokenExceptions, you do not want to convert those to Fault Exceptions right away. You actually do want to throw these as SecurityTokenExceptions in the custom validation in order for the service/server to recognize that the security authorization failed, and automatically returns as a fault equiv of a "403 : Access Denied". I am not 100% but I think that the custom auth and validation pieces happen before custom service behaviors, like the error handler, are loaded. Unfortunately, if you need to troubleshoot something in your auth, you will need to turn on WCF tracing on the service, see this article titled "How to turn on WCF Tracing".
If you need to log failed auth attempts, you will probably need to put it directly in your custom validator.
I'm trying to write a WCF 4.0 service that will receive SOAP alerts from TFS 2010. Here is my service contract:
[ServiceContract(Namespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
public interface IService1
{
[OperationContract(Action = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify")]
[XmlSerializerFormat(Style = OperationFormatStyle.Document)]
void Notify(string eventXml, string tfsIdentityXml);
}
I am using this binding configuration for my service endpoint:
<bindings>
<wsHttpBinding>
<binding name="noSecurity">
<security mode="None"/>
</binding>
</wsHttpBinding >
</bindings>
Having registered a TFS alert using BISSUBSCRIBE.EXE and pointed it to my service, every time it is triggered my service is not invoked and instead I see the following in the TfsJobAgent log:
Notification not delivered.
Notification: WorkItemChangedEvent (DeliveryType: Soap; Address: http://192.168.10.10/TrafficLight/Service1.svc)
Exception: Microsoft.TeamFoundation.TeamFoundationServiceUnavailableException: Team Foundation services are not available from server http://192.168.10.10/TrafficLight/Service1.svc. Technical information (for administrator):
HTTP code 404: Not Found ---> System.Net.WebException: The remote server returned an error: (404) Not Found.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.AsyncWebRequest.ExecRequest(Object obj)
--- End of inner exception stack trace ---
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ProcessHttpResponse(HttpWebResponse response, Stream responseStream, WebException webException, XmlReader& xmlResponseReader)
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ExecWebServiceRequest(HttpWebRequest request, XmlWriter requestXml, String methodName, HttpWebResponse& response)
at Microsoft.TeamFoundation.JobService.Extensions.Core.TeamFoundationNotificationClient.Notify(String eventXml, String tfsIdentityXml, Subscription subscription)
at Microsoft.TeamFoundation.JobService.Extensions.Core.NotificationJobExtension.SendSoapNotification(TeamFoundationRequestContext requestContext, TeamFoundationNotification notification, TeamFoundationIdentityService identityService)
(This is taken from the [Tfs_Configuration].[dbo].[tbl_JobHistory] table of my TFS 2010 installation)
Oddly enough, when I try my service's URL in internet explorer on the same machine where the TfsJobAgent is running, I receive the standard "You have created a service." web page auto-generated by WCF and not a 404 error.
At last, my question: Why is the TFS Job Agent receiving a 404 error from my service which seems to be properly configured? How can I resolve this issue?
Update: I've tried rewriting my service as an ASMX web service and it's working well. Below is the implementation. I still want to learn how to achieve the same using WCF 4.0 so any help would be greatly appreciated.
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
public class WebService1 : System.Web.Services.WebService
{
[SoapDocumentMethod("http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
[WebMethod]
public void Notify(string eventXml, string tfsIdentityXml)
{
// log incoming event...
}
I have created this succesfully - http://www.ewaldhofman.nl/post/2010/08/02/How-to-use-WCF-to-subscribe-to-the-TFS-2010-Event-Service-rolling-up-hours.aspx - and it seems that you are using the same steps.
Did you also specify the wsHttpBinding for the endpoint?
I am developing WCF services with basicHttpBinding, these services should be accessible using .net 1.1 & .net 2.0, for this purpose I am using basicHttpBinding. In old ASMX web services I assed one Soap Header (AuthHeader) to authenticate the user every request.How Can I authenticate in WCF using basicHttpBinding? Any sample Or tutorial will helpfull.
nRk
You can use AuthHeader as you did before switching to WCF. Maybe it will be more convinient for you, cause the princples will remain the same.
The bad thing i see in this solution is a plain text password transfer. Anyway, it's just another option and you can encrypt/decrypt the password somehow.
In this case you should implement your own your IDispatchMessageInspector & IClientMessageInspector, like
[AttributeUsage(AttributeTargets.Class)]
public class CredentialsExtractorBehaviorAttribute : Attribute, IContractBehavior, IDispatchMessageInspector
{
#region IContractBehavior implementation.
public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint,
DispatchRuntime dispatchRuntime)
{
dispatchRuntime.MessageInspectors.Add(this);
}
... empty interface methods impl skipped ...
#endregion
#region IDispatchMessageInspector implementation.
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
int i = request.Headers.FindHeader("username", "sec");
if (-1 != i)
{
string username = request.Headers.GetHeader<string>("username", "sec");
... do smth ...
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState)
{
return;
}
#endregion
}
In a sample i placed to header only username, but you can implement your a class containing username and password and use it instead of string.
On the client:
internal class CredentialsInserter : IContractBehavior, IClientMessageInspector
{
private string m_username;
public CredentialsInserter(string username)
{
m_username = username;
}
#region IContractBehavior implementation.
... empty interface methods impl skipped ...
public void ApplyClientBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint,
ClientRuntime clientRuntime)
{
clientRuntime.MessageInspectors.Add(this);
}
#endregion
#region IClientMessageInspector implementation.
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
MessageHeader<string> mh = new MessageHeader<string>(m_username);
request.Headers.Add(mh.GetUntypedHeader("username", "sec"));
return null;
}
public void AfterReceiveReply(ref Message reply, object correlationState)
{
return;
}
#endregion
}
Then you should place attribute CredentialsExtractorBehaviorAttribute on your service implementation class.
[CredentialsExtractorBehavior]
public class DummyService : IDummyService
{
... impl ...
}
And on the client side you should do the following:
using (DummyServiceClient c = new DummyServiceClient("TcpEndpoint"))
{
c.ChannelFactory.Endpoint.Contract.Behaviors.Add(
new CredentialsInserter("_username_"));
c.DummyMethod();
}
First of all - yes you can! It depends on whether you use Transport or Message binding - if you're internet-facing, you're more likely to use message-based security.
Unfortunately, for message-based security, basicHttpBinding only supports certificates which is a bit of a pain.
wsHttpBinding on the other hand would support username/password or other methods as well.
You'd configure wsHttpBinding with username/password client credentials over message-based security like this:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsUserName">
<security mode="Message">
<message clientCredentialType="UserName"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="yourservice">
<endpoint name="YourEndpoint"
address=""
binding="wsHttpBinding"
bindingConfiguration="wsUserName"
contract="IYourService" />
</service>
</services>
</system.serviceModel>
The section under <bindings> defines a binding configuration for wsHttpBinding that uses message-security with username/password client credentials.
The section under <service> defines a sample service that uses wsHttpBinding and that references that binding configuration that we just defined.
On the server side, you could now use the username/password that's being sent over the wire to validate your callers either in your Active Directory (everyone calling needs an AD account with you), or in the ASP.NET membership system database; or if you really really must, you could write your own authentication mechanism, too.
Find a lot of useful information on WCF security at Codeplex - excellent resource.
Check the scenarios here to try to match one to your situation. Each scenario is provided with a chceklist of items required to implement the solution.
I have a net tcp WCF service as follows
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class AVService : IAVService
{
static int _numberofInst = 0;
public AVService()
{
++_numberofInst;
Console.WriteLine("Number of instances "+_numberofInst);
}
~AVService()
{
--_numberofInst;
Console.WriteLine("Number of instances " + _numberofInst);
}
public void Foo(){}
}
When I create an object on the client side as follows
AVService client = new AVService();
client.Foo();
The constructor is called, but when I close the client application without calling close mehotd, the destructor does not been called? why? does this mean the service object still works on the server?
Yes - if you don't explicitly dispose of your client, the server will "hang around" for a while (since you specified PerSession mode).
It will eventually time out (specified by the InactivityTimeout setting on the binding configuration), and will be destroyed. But that could take some time (several minutes to several hours, depending on your settings).
<bindings>
<netTcpBinding>
<binding name="NetTcp_Reliable" receiveTimeout="00:20:00">
<reliableSession enabled="true" ordered="false"
inactivityTimeout="00:15:00" />
</binding>
</netTcpBinding>
</bindings>
Therefore, it is the best practice to always dispose of your client before closing the app.