The flowed transaction could not be unmarshaled. The following exception occurred: The WS-AtomicTransaction protocol service could not unmarshal the flowed transaction. The following exception occured: A fault reply with code CoordinatorRegistrationFailed was received. The fault reason follows: The WS-AT protocol service failed to register with its coordinator. A connection could not be established.
I am using WCF Service
When I use Transacton in nettcpbinding over internet
it Work Completly on the LAN network
This worked for me. You may try this.
Open component services in server machine and expand component services and then expand computers expand my computer and expand distributed transaction coordinator right click local DTC open properties: Go to Security tab, enable Network DTC Access and then enable Allow Inbound in Transaction manager communication leave other settings.
Now open Component Services in Client machine follow above and go to local DTC properties open security tab , enable Network DTC Access and then enable Allow Outbound in Transaction manager communication leave other settings.
Related
I am using WCF with NetTcp binding and castle windsor as dependency injection at client side.
I am recieving Socket exceptions at client side sometimes, not always. Tried with different config setting but no luck. exceptions occruence are completely random.
few error messages:
An existing connection was forcibly closed by the remote host
System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Security.SecuritySessionClientSettings`1+ClientSecurityDuplexSessionChannel[System.ServiceModel.Channels.IDuplexSessionChannel], cannot be used for communication because it is in the Faulted state.
Error loading CubeDrillThroughAttributeSets cache: System.ServiceModel.ProtocolException: This channel can no longer be used to send messages as the output session was auto-closed due to a server-initiated shutdown. Either disable auto-close by setting the DispatchRuntime.AutomaticInputSessionShutdown to false, or consider modifying the shutdown protocol with the remote server.
Error loading Locations cache: System.ServiceModel.CommunicationObjectAbortedException: The communication object, System.ServiceModel.Security.SecuritySessionClientSettings`1+ClientSecurityDuplexSessionChannel[System.ServiceModel.Channels.IDuplexSessionChannel], cannot be used for communication because it has been Aborted.
WCF service is configured with PerCall instance mode.
At the client side, I am using dependency injection to inject WCF service proxy (proxy is created using channel factory).
I am not explicitly opening/closing connection with WCF service and leaving this to DI.
already tried using google. my questions are...
using DI for proxy management is good?
How the life time of proxy will be managed.
These proxies are injected in construtor when user select to load some screens in UI app. Can these proxy be timedout as per defined in client app.config file if user just open some screen and not doing anything. if yes, then what is the good way for not to timedout.
are these proxy using WCF connection pooling feature.
Thanks in advance.
I have my binding specified like this in the Service hosted in windows server 2008.
<bindings>
<wsHttpBinding>
<binding name="transactionalWsHttpBinding"
transactionFlow="true" />
</wsHttpBinding>
</bindings>
I have not installed the WSAtomicTransaction roles in the server where the service is hosted.
when I am trying to consume the above hosted service from a different machine, I am getting the following error message.
The flowed transaction could not be unmarshaled. The following exception occurred: The MSDTC transaction manager's WS-AtomicTransaction protocol service 'Version10' is disabled and cannot unmarshal incoming transactions.
should I install the ws-atomic feature ? If I am trying to install the WSAtomic transaction feature in Server, I am forced to add a certificate, should I implement the certificate based authentication?
This worked for me. You may try this.
Open component services in server machine and expand component services and then expand computers expand my computer and expand distributed transaction coordinator right click local DTC open properties:
Go to Security tab, enable Network DTC Access and then enable Allow Inbound in Transaction manager communication leave other settings.
Now open Component Services in Client machine follow above and go to local DTC properties open security tab , enable Network DTC Access and then enable Allow Outbound in Transaction manager communication leave other settings.
I have two windows services. One ('server') acts as a WCF host to which the other ('client') connects. So I have configured a dependency from client to server. Both are also set up to start automatically.
When I start these services by hand, everything works fine. When I stop both services and tell client to start, then server will be started before client and all is fine.
However, when I reboot the machine only server is started.
When I add a diagnostic listener I see it got a TimeoutException with the helpful message:
The HTTP request to 'http://[server address]' has exceeded the allotted timeout of 00:00:00. The time allotted to this operation may have been a portion of a longer timeout.
At some other SO question there was an answer that claims WCF is probably confused about what went wrong and therefore starts lying about the timeout.
Did I perhaps miss a dependency for either service? Does WCF require something that hasn't or is being started when client is trying to contact server?
I think you should check your client service. On startup windows services are starting while network devices are still being initialized. Services should be ready to start without network and without any network device. Usual approach is to keep periodic retries to establish connection. You can do little experiment on your machine by uninstalling all network adapters and trying to start up your services.
Additional quick workaround you can do is to setup recovery options on your service -- for example you can configure it to restart service on crash after some timeout -- you can do this through UI in services.msc or in command line using 'sc config' command.
Configuring the dependency between the two Windows Services is not necessarily sufficient to avoid there being a race condition: i.e. to avoid the client service calling the WCF service before the server's WCF channel stack is fully initialised.
The service dependency just ensures that the Windows Service Control Manager won't start the client service process before the server Windows Service has notified the SCM that it has started. Whether this is sufficient depends on how you write the server.
If the server service starts a new thread on which to initialize the WCF stack, your OnStart method is probably returning before the WCF stack is ready for clients. There is then a race condition as to whether the client's first call will succeed.
On the other hand, if the server service does not return from OnStart (and thus doesn't notify the SCM that it has started) until the channel stack is fully open, the dependency removes the race condition, but there is a different pitfall: you need to beware that the SCM's own timeout for starting the Windows service is not triggered while waiting for the WCF stack to initialise, as might well happen on a reboot if the WCF service depends on the network stack, for example. If the server's OnStart does not return within the SCM's timeout, the SCM will not try to start the dependent client service at all, because it does not receive the server's start notification. (There will be a message in the Windows event log from the SCM saying that the server service didn't start within the expected time.) You can extend the SCM timeout by calling ServiceBase.RequestAdditionalTime while the WCF service is being initialised.
Either way, the client service really ought to be written so that it doesn't fail completely if the first WCF call doesn't succeed.
You don't actually say what binding you are using. If client and server services are always running on the same machine, as you seem to indicate, then consider using the NetNamedPipeBinding: then your service won't be dependent on initialization of networking resources and startup should be quicker.
I am getting the following error trying to communicate from WCF -> WCF across the internet with a SSL certificate. I have 'No authentication required' checked in the WS-AT configuration on the server.
After a few seconds I'm getting the following message on my client, and trying to figure out what is wrong in my configuration (or understanding of WS-AT).
The flowed transaction could not be
unmarshaled. The following exception
occurred: The WS-AtomicTransaction
protocol service could not unmarshal
the flowed transaction. The following
exception occured: A fault reply with
code CoordinatorRegistrationFailed was
received. The fault reason follows:
The WS-AT protocol service failed to
register with its coordinator. A
connection could not be established.
Looking at the log file on the server I find a link to http://msdn.microsoft.com/en-us/library/aa702582(VS.90).aspx and the following trace message
Microsoft.Transactions.TransactionBridge.RegistrationCoordinatorFailed
Traced if the local TransactionManager is not able to
Register with its superior
TransactionManager due to the
inability to send a message.
So I'm wondering... is the server attempting to communicate with the client through a different channel to the SSL connection originally established by the client. I'm pretty sure thats what it's trying to do for me to end up with this message. The client is my laptop (currently in Starbucks) so there's no chance of any incoming connections.
So is it possible to use WS-AT transactions where only the server has an open firewall? Assuming it is possible - what do i have to do to allow for it? I'm finding very little information about necessary configuration - even in my massive Programming WCF book .
Bonus: Here's a few small tips for anyone trying to get WS-AT working :
If when trying to install the WS-AT tab you can't get it to appear - and you're running an x64 operating system - make sure you're using the x64 version of RegAsm.exe:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe /codebase wsatui.dll
If once installing WS-AT, configuring it for incoming connections and restarting MCAT you still get errors about the protocol being disabled you may have forgotton to restart IIS(!)
I am facing two issues when i try to connect to MQ which is deployed on a Remote Server from Weblogic Server(WLS) by creating a Foreign Server.
1. When I try to connect to MQ Queuemanager in Bindings mode(after importing the .Bindings file) i keep getting the below error in WLS console:
java.lang.UnsatisfiedLinkError: no mqjbnd05 in java.library.path
If i Switch the Transport to Client i keep getting:
JMSWMQ0018: Failed to connect to queue manager '' with connection mode 'Client' and host name 'localhost'. Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.
Has anyone seen this, and are there any performance implications which dictate the use of client over bindings and vice versa?
TIA
Finally i was able to resolve this, i had to recreate the .bindings file in the client mode, with changes to the IVTsetup.bat which is most likely present in
C:\Program Files\IBM\WebSphere MQ\java\bin, I had to run this
def qcf(psQCF) TRANSPORT(CLIENT) HOST(SMEKA) PORT(1415) CHANNEL(ps_SRV_CHANNEL) QMGR(psQM)
to generate the .bindings file.
Refer to this link for more details:
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_adapters.doc/doc/peoplesoft/peopleso103.htm
Where the question states that I try to connect to MQ which is deployed on a Remote Server from Weblogic Server I assume this means that WLS and WMQ are on two different hosts. If that is the case, then a bindings mode connection (which relies on shared memory segments) won't work.
The client mode connection appears to be using a CF that is pointed to localhost rather than the IP or hostname of the WMQ server. This would work for an application on the same host as the queue manager but not when the app and QMgr are on separate servers.
As far as choosing between client and bindings mode, the answer is that if the QMgr is local use bindings. This provides highest reliability, best performance and XA transactionality. When using client mode, two-phase XA commit is not supported without the Extended Transactional Client. Per the JMS specification, there is an ambiguity that can exist if an app loses the connection during a COMMIT call. Depending on how the app handles this it's possible to end up with duplicate messages. (The JMS spec refers to these as "functionally duplicate.") This ambiguity is much less likely to occur with a bindings mode connection since there is no network latency and not even any traversal of the IP stack or interface. So use bindings mode where possible.
UPDATE:
Removed note about Extended Transactional Client being a chargeable component. As of April 24th, XTC is free of charge for all versions of WMQ on all platforms.