Service not working on new machine

Apr 11, 2011 at 1:09 PM

Hi Thomas,

I have a weird issue on a new machine we have just installed. We have a windows service which has been running for over a year. On the dev machine, it is working fine but when deployed to the new server, the iterator is never kicked off although we get no exceptions from the Post? Basically, in the service constructor, it looks like this

_space = new XcoAppSpace(

);   

_worker = _space.RunWorker(new PQueueToProcessWorker 

());
 

_queueProcessedResponsePort = _space.Receive<int

>(resp => CompletedQueueProcessing());

There i method which polls our database and looks for items to work on, when it finds one, it posts to the

QueueToProcess qtp = new QueueToProcess();

qtp.outputMediaQueueToProcess = oq.Key;

qtp.ReponsePort = _queueProcessedResponsePort;

 

 

SiAuto.Main.LogMessage("About to post {0}", oq.Key);

_worker.Post(qtp);

Here's the implementation,

public class PQueueToProcessWorker : Port<QueueToProcess> XcoConcurrent] 

 IEnumerator<ITask> ProcessEntriesForMediaQueue( QueueToProcess

qtp )

{

etc etc

However, the method ProcessEntriesForMediaQueue never gets called? On every machine this has been running on its worked but not this machine (windows Server 2008 R2).

I have two other services which use Pub / Sub and on the same machine and they work perfectly so wondered if you had any ideas or how to troubleshoot.

Any help gratefully received

Kind regards

Mike

 



{[

Coordinator
Apr 11, 2011 at 6:05 PM

Hi Mike,

I fear that I don't have any particular idea as to what the problem could be. Some suggestions though for further investigation:

  • Have you tried to switch on logging to see if there are any messages at all arriving at the appspace? (Probably there are messages arriving, since ConnectWorker would fail if they didn't - in any case, the log would show if the messages really arrived and were given to the worker)
  • I encountered a problem once with ccr iterators not being called, although it wasn't as severe as yours - you could try removing the iterator and see if the message arrives then (although it would be very strange that this would only occur on a certain machine).
  • Other things I would try are checking the .Net Framework installation (and reinstall it if needed), and restarting the server (but I assume you probably did that already)

Best Regards
Thomas

Apr 11, 2011 at 6:30 PM

Hi Thomas,

Thanks for the reply. I have as little ideas as you have!

Just so I understand, If I copy all the diagnostic settings that have been shown on the logging mechanisms page into the app.config, should that be enough (I'm using DebugView to see the output).

Also, after I post the message, should I be able to see it on the port by calling Test() or getting the ItemCount or will it have been consumed already by the dispatcher behind the scenes? I'm trying to see if the message is just sitting on the port or in the queue?

Thanks in advance

Mike

 

Coordinator
Apr 12, 2011 at 7:17 AM
Edited Apr 12, 2011 at 7:22 AM

Hi Mike,

I am not familiar with DebugView, but if it catches the standard debug window output, then yes it should work with the configuration from the logging mechanisms page. If not, then you probably need to configure a special trace listener. You can also easily log the output to a file, see for example here for configuration instructions:
http://weblogs.asp.net/ralfw/archive/2007/10/31/code-instrumentation-with-tracesource-my-personal-vade-mecum.aspx

Concerning your second question, if the message hasn't yet been processed then yes you should be able to still see it in the Port using Test() or ItemCount. Of course only if the Dispatcher really didn't grab it - if something really went wrong within the Dispatcher itself then the message will probably be gone already.

Thomas

Apr 12, 2011 at 8:03 AM

Hi Thomas,

I did this yesterday but I'm not getting anythng in the log file at all? Just so I understand, do I need to do anything in my code i.e. Do I need to add any trace statements or is this baked into the AppSpace libraries so all I should need to do is add the listener config to the app.config and then start my service and I should see tracing information?

I think this is going to be one of those nasty, unexplainable things that makes you want to eat chocolate and go play golf!

If there was an actual error of some sort that was happening behind the scenes, where would I see that error informationo try and look for it - Would this happen or would I just normally see and unhandled exception somewhere?

Thanks again for the support

Mike

Coordinator
Apr 12, 2011 at 12:22 PM

Hi Mike,

Here is a config I used once for logging into a File, this should work:

  <system.diagnostics>
  <trace autoflush="true"/>

		<sources>
			
<source name="XcoAppSpaces.Core" switchName="DefaultSwitch">
        <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
	  
			<source name="XcoAppSpaces.Core.Communication" switchName="DefaultSwitch">
			<listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Core.Communication.WorkerResolve" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Transport.Sockets" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Transport.WCF" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Transport.MSMQ" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Transport.Jabber" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
      <source name="XcoAppSpaces.Security.Basic" switchName="DefaultSwitch">
	  <listeners>
          <remove name="Default" />
          <add name="TextFileListener" />
        </listeners>
      </source>
    </sources>
		<switches>
			<!-- Debug Level = "Verbose", Turn Off = "Off" -->
			<add name="DefaultSwitch" value="Verbose" />
		</switches>
		<sharedListeners>
			<add name="TextFileListener" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime" initializeData="test.log" />
		</sharedListeners>
	</system.diagnostics>

Hope this helps! You don't need to do anything in code, so the config alone is enough.

You can also check the appspace error port to see if any errors are posted there (property XcoAppSpace.ErrorPort) - this port is used if any internal errors occur that are not handled by causalities.

Thomas