none
Connecting to web service | unable to get request | Clear aaplication pool works fine RRS feed

  • Question

  • Hi,

    In my application I have to connect to web service and get the results. Currently it's a public property as I have so many calls to service. I'm aborting and closing the service only when the service goes to faulted state. My application is hosted in IIS 7.5. When I deploy my appication to IIS it's working fine for some time. When the application is idle for some time(for eg., a day), the next day my application related to service call module is not working.

    It works only when I recycle the application pool. What would be the issue here? What is the best way to connect to the webservice if there are so many calls to webservice? Do I need to create new client every time or is there any other way?

    If you need any more clarifications, please let me know. This is urgent.

    Thanks in advance.


    Sab

    • Moved by Bob Shen Friday, April 12, 2013 7:19 AM
    Thursday, April 11, 2013 3:19 AM

All replies

  • You request is a little vague, but I can give some pointers

    1) Yes you need to create a new client each time.  I usually create a list[client] like this

    List<Myclient> clients = new List<Myclient>();

    Using a List<> allows you to delete the faulted clients from the middle array.  Make sure you dispose the client when you remove it to get rid of all the child objects

    2) Check the Event viewer to see if there are any error message to indicate why the connections went to the faulted states

    3) Don't close a client connection from your server.  the close should always come from the client end.  A race condition can occur if both the server and client attempt to close a connection at the same time.

    4) If the service always stops working around the same time at night, there may be something that run at night that is killing your service like backups or an application that yoiur MIS department runs at night.

    5) There is a bug with reopening a client class after it has been closed.  You must call the constructor again

    TCPClient client = new TCPClient();

    your code here

    client.Close();

    client.Open();      <---  this won't work after a Close()

    client = new TCPClient();      <-----  Use this instead


    jdweng

    Thursday, April 11, 2013 4:54 AM
  • Thanks Joel.

    Can you please tell me what are other inputs you need(bcoz you told question is vague).

    There is nothing in EventViewer or server side. Is it the right way to create client each time because I have so many calls to the service, its like gui -> server -> service -> server -> gui. How to dispose the clients properly?


    Sab

    Thursday, April 11, 2013 6:05 AM
  • Hi,

    As per my knowledge, WCF has a timeout and it will holds a connection open for 10 mins by default, when you recycle the app pool all connections are closed, and therefore things work again. Please try fix it by checking your code to make sure you have close connections( call Close method at client side) or dispose proxies when you do not used them.

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, April 12, 2013 9:04 AM
    Moderator
  • After specific minutes of no activity, IIS 7.5 shuts down the IIS worker process and ideally it should wake up again when a new request arrives. i belive for some reason this is not happening as expected.

    Check if it can be for any other faulty application/service which is sharing the same application pool.

    Following solution may applicable for you.

    1. Configure Auto-Start in IIS 7.5 should works fine.
    2. Otherwise you can disable IIS idle timeout

    Lingaraj Mishra

    Sunday, April 14, 2013 12:23 PM
  • Thanks Haisia.

    My application calls the webservice frequently. So I have one public property in client side, otherwise every time I have to open and close the client which is another overhead. I'm closing and reopening only when the client is in FAulted state.

    How to increase the timeout from 10 mins to maximum? Is it the right way to do?

    And I noticed one more wierd thing today. On Saturday when I checked, service was not working and I found the below error in server side,

    FATAL Services.ErrorHandler -
    FATAL ERROR OCCURED : The message with To 'http://machinename/service.svc/mex/mex' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver's EndpointAddresses agree.
    Stacktrace :    at System.ServiceModel.Dispatcher.ErrorBehavior.ThrowAndCatch(Exception e, Message message)

    But today the service is working fine and I'm able to consume it. No one has changed anything and anywhere. We didnt recycle application pool also.


    Sab




    • Edited by Sab Venkat Monday, April 15, 2013 3:09 AM
    Monday, April 15, 2013 2:21 AM
  • Thanks Linghraj. But is this acceptable in production environment?

    Sab

    Monday, April 15, 2013 2:21 AM
  • Hi,

    If you want to make the client and server keep connection for a long period, you can set receiveTimeout as large as possible.

    >>'http://machinename/service.svc/mex/mex'

    Notice that you used two "mex", please check if it is the issue.

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, April 15, 2013 11:38 AM
    Moderator
  • Thaks Haixia.

    I made some logging and I found the below error from client side.
    This happens when I just open the silverlight page and keeping it idle for some time and accessing after some time. I have changed the receive timeout to 5 days in server. Do I need to change anything else in client config also?

     

    Log Entry : 05:33:46 mercredi 17 avril 2013
      :
      :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/ISample/Sample' 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.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 .....
    -------------------------------

    Log Entry : 05:33:46 mercredi 17 avril 2013
      :
      :An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
    -------------------------------

    Log Entry : 05:33:46 mercredi 17 avril 2013
      :
      :System.ServiceModel.FaultException: The message could not be processed. This is most likely because the action 'http://tempuri.org/ISample/Sample' 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.
    -------------------------------


    Sab

    Wednesday, April 17, 2013 3:43 AM
  • Hi,

    You need update the service reference for client after modifying the service and make sure the binding configurations are matched.

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, April 17, 2013 10:15 AM
    Moderator
  • Why should I need to update the service reference? The change in service is just receivetimeout and how does it affects the client?

    Sab

    Thursday, April 18, 2013 6:42 AM
  • Hi,

    The metadata for the service may change, requiring that the service reference be updated.

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, April 18, 2013 6:52 AM
    Moderator
  • No, it's not working.

    Sab

    Sunday, April 21, 2013 5:19 AM