Options

Nas and maillog issues

lzrlzr Member Posts: 264
Our system is currently running Navision 4.0 sp1 with SQL 2005. I installed NAS and the maillog runs as it should. However it crashes like 5 times a day and I have to manually restart the service. As I can see there are 3 different crashes so far.

1. Nassql crashes and has to be manually started. Event viewer says:
The following information is part of the event: nassql.exe; 4.0.1.21666; 430b5706; ntdll.dll; 5.2.3790.1830; 424377d2; 0; 000396d0.

2. Event viewer gives a c/al warning and echoes this warning until I restart the service. Event viewer says:
The following information is part of the event: This message is for C/AL programmers:

The call to member Logon failed. Collaboration Data Objects returned the following message:
[Collaboration Data Objects - [MAPI_E_INVALID_OBJECT(80040108)]]

3. The maillog just stop logging, no error or warning is reported in the event viewer.

Anyone have any ideas?
Navision developer

Comments

  • Options
    mjrogersmjrogers Member Posts: 59
    Did this setup ever work on other versions of SQL/Navision?

    We had similar problems with an installation recently, and although the problem finally turned out to be a bug in Navision, we initially had no idea what was causing NAS to crash.

    We used the SQL profiler to log what activity was going on. We also monitored activity and growth of the logfile. This gave us some important information which led us on to finally resolving the issue.

    Unfortunately I can't help with the specific message you are getting but I hope my tips help you find the issue.
    TecSA Malaysia

    Those of you who think you know everything are annoying to those of us who do. -
    David Brent
  • Options
    lzrlzr Member Posts: 264
    Yes, it worked when we were running Navision 4.0 with native database.

    Might be a bug, but then again it is strange there are 3 different reasons..

    anyway thanks for your input.
    Navision developer
  • Options
    krikikriki Member, Moderator Posts: 9,098
    lzr wrote:
    Our system is currently running Navision 4.0 sp1 with SQL 2005. I installed NAS and the maillog runs as it should. However it crashes like 5 times a day and I have to manually restart the service.
    Can't you put in the service that Windows has to restart the service when it crashes? (see recovery-tab of the service)
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • Options
    lzrlzr Member Posts: 264
    Good idea! I'll do that. Should sort out at least one of the problems.

    Anyone noticed any similar problems with the NAS SQL 4.0 SP1?
    Navision developer
  • Options
    Scott_FrappierScott_Frappier Member Posts: 90
    Hello everyone!

    I see that this is a fairly old post. I was wondering if anyone has ever found out what was going on with it as we're running into it as well.

    From what I can tell - it looks to be caused by MAPI because the design of the codeunit looks to CREATE COM objects, but never releases them. I have tried numerous things, from changing all automation controllers to globals, to CLEAR functions after everything is said and done. I still run into the same issue if there are a number of emails, or over a period of time with a very busy email site.

    I created a basic design in C# that also used the Marshal.ReleaseComObject method and I cannot re-create this issue. My guess is that the CLEAR() function does not actually release the COM object in NAV, and there are RPC connections open between Exchange and NAV but I can't seem to pinpoint it...

    I'm almost ready to re-design this in C# so that it also works with Exchange 2010, as the new journaling functionality creates journal reports with the original message as an attachment (so the Sender method used in CDO does not work). Anyone tackled this by chance?

    Any info would be appreciated.

    Thanks!
    Scott Frappier
    Vice President, Deployment Operations

    Symbiant Technologies, Inc.
    http://www.symbiantsolutions.com
  • Options
    danlindstromdanlindstrom Member Posts: 130
    Hello everyone!
    ...
    From what I can tell - it looks to be caused by MAPI because the design of the codeunit looks to CREATE COM objects, but never releases them. I have tried numerous things, from changing all automation controllers to globals, to CLEAR functions after everything is said and done. I still run into the same issue if there are a number of emails, or over a period of time with a very busy email site.
    ...

    Youre on the right track. We had similar problems and after installing a hot fix of codeunit 5064+5065 (maillog dispatcher + logging) it works well.
    The key part is that the old logging-codeunit logged in and out from Exchange server every time it had to check the queue-folder.
    After the fix NAS only logon once and dont release the conection to the Exchange server (it had been implemented in later versions)
    Regards
    Dan Lindström
    NCSD Navision 2.00 since 1999 (Navision Certified Solution Developer)
    MBSP Developer for Microsoft Dynamics NAV 2009
  • Options
    Brett_BarabashBrett_Barabash Member Posts: 9
    Dan, where did you obtain the hotfix for this? I can't see anything on PartnerSource.

    Aside of using the Job Queue table, NAV 2009 R2 still operates in a similar manner, logging on and off between job runs. I have tried everything for one of my customers running 4.02 including using the newest 5064/5065 codeunits and NASAppHandler.dll. It still results in NAS freezing for long periods followed by the error message in the original post.

    Brett
  • Options
    Brett_BarabashBrett_Barabash Member Posts: 9
    I'm almost ready to re-design this in C# so that it also works with Exchange 2010, as the new journaling functionality creates journal reports with the original message as an attachment (so the Sender method used in CDO does not work). Anyone tackled this by chance?

    I tried writing preprocessing code in 5064 to go through the journal messages and save the attachments to a separate folder before the standard code runs. Problem was, certain messages would trigger CDO errors. Usually it was the auto-generated Exchange Administrator ones, but there were some external senders that would cause it to fail as well.

    I recently discovered from this article that setting up hub transport rules to BCC internal and external messages to a different mailbox works much better.

    Brett
  • Options
    Scott_FrappierScott_Frappier Member Posts: 90
    Brett:

    Hope business is going well for you! I think the last time we had contact with you was at your previous employer! :)

    I was never able to fully fix the issue - even with the hotfix. I would run into a number of different issues - from COM/Automation errors to just plain weird NAS issues. Instead of fighting the issues as we even tried to re-create them with Microsoft, I decided to get things up and running where it will not cause issues for the client.

    First thing was getting past the journaling - we used the BCC functionality in the Message Hub Transport to correct the issue with Exchange 2010. This worked for our environment as they only have one server, but from what I've heard and read, if you have a large organization with many emails - this can cause a significant performance issue on the Exchange Server. We also developed an integration with another custom automation controller called "Redemption" that extends CDO past where Microsoft left it at in 1.21. Google it if you're curious - we used the "SentOnBehalfOf" method to get information regarding who sent the email so that we didn't retrieve the Exchange system attendant email.

    Secondly - We've had issues with Outlook 2007 and 2010 and MAPI/CDO - we decided to create a new virtual server using Windows Server 2008 R2 and loaded NAS/Classic Client and Outlook 2003 SP2 on the machine. Set it to 512MB of RAM and the server basically uses no resources but it is an isolated environment that we know works well with Outlook.

    After all of the basic setup with the NAS, Job Queue, and Client for Folders - we made the following code changes in codeunit 5064 to account for "real-world" data that we found (i.e. no senders which caused it to error on the same message over and over and also no subject which caused the message filter to fail):

    Function
    RunEmailLogging()
    ...
    = WHILE NOT ISCLEAR(CDOQueueMessage) DO BEGIN
    =   TempSegLine.DELETEALL;
    =   TempSegLine.INIT;
    =   Continue := FORMAT(CDOHandler.GetSensitivity(CDOQueueMessage)) = '0'; // CdoNoSensitivity
    =   
    +  //>> SYM/SF
    +  Continue := CDOHandler.SenderExists(CDOQueueMessage);
    +  //<< SYM/SF
    =
    =  IF Continue THEN
    =    Continue := NOT AlreadyInStorage(CDOQueueMessage);
    ...
    

    Function
    IdentialItemInStorage(VAR CDOQueueMessage, VAR CDOStorageMessage)
    ...
    = SenderVariant := CDOQueueMessage.Sender;
    = IF SenderVariant.ISAUTOMATION THEN
    =   CDOStorageMessageFilter.Sender := CDOQueueMessage.Sender;
    =
    + //>> SYM/SF
    + //CDOHandler.SetSubjectComparisonField(CDOStorageMessageFilter,CDOQueueMessage);
    + IF STRLEN(CDOHandler.GetSubjectSubString(CDOQueueMessage,1,10)) > 0 THEN
    +   CDOHandler.SetSubjectComparisonField(CDOStorageMessageFilter,CDOQueueMessage);
    + //<< SYM/SF
    +
    = CDOStorageMessage := CDOStorageMessages.GetFirst;
    ...
    

    Function
    AddressEntryEmail(VAR CDOAddressEntry, Return Code(250))
    Added CDOValue(local) = Variant
    ...
    = WHILE FieldNumber > 0 DO BEGIN
    =   CDOField := CDOFields.Item(FieldNumber);
    +   //>> 001 SYM/SF
    +   CDOValue := CDOField.Value;
    +   IF CDOValue.ISTEXT OR CDOValue.ISCODE THEN
    +   //<< 001 SYM/SF
    =     IF STRPOS(FORMAT(CDOField.Value),'@') <> 0 THEN
    ...
    

    Once all of the code was working properly and we didn't see processing errors - we started noticing MAPI errors due to the connection never closing properly. To correct this and keep from running a hot fixed codeunit until another release addresses it, we went down the old fashioned way.

    We created two scheduled jobs with batch files. The first was called "RestartNAS.bat" and the other was called "StartService.bat".

    RestartNAS.bat contained the following:
    @ECHO OFF
    for /F "tokens=3 delims=: " %%H in ('sc query NASSERVICE-SQL ^| find /i "STATE"') do (
      if /I "%%H" == "RUNNING" (
       ECHO Service is running and a stop command has been issued
       net stop NASSERVICE-SQL
      )
      ECHO Service has been sent the start command
      net start NASSERVICE-SQL
    )
    

    StartService.bat contained the following:
    @ECHO OFF
    for /F "tokens=3 delims=: " %%H in ('sc query NASSERVICE-SQL ^| find /i "STATE"') do (
      if /I "%%H" NEQ "RUNNING" (
        ECHO Service has been sent the start command
        net start NASSERVICE-SQL
      )
    )
    

    Two jobs were created in the Windows Task Scheduler (Start --> All Programs --> Accessories --> System Tools):
    [*] First Job was called Restart Application Server. The "Trigger" for this was "On an Event" and the "Custom" Event Filter looked for any Critical, Warning, or Error states for the service. It would then execute the "RestartNAS.bat" file with the highest privilege. The XML event filter looked as follows:
    <QueryList>
      <Query Id="0" Path="Application">
        <Select Path="Application">*[System[Provider[@Name='NASSERVICE-SQL'] and (Level=1  or Level=2 or Level=3)]]</Select>
      </Query>
    </QueryList>
    

    [*] The second job would check to make sure that the NAS was running - just in case we ran into a condition where it stopped during the previous process for some unknown reason. It was set to execute daily and would repeat every 5 minutes. It would execute the StartService.bat file which checks to see if the service is running, and if so does nothing, otherwise it starts the service.

    After we implemented these changes, we have seen the application process all emails without issues - it no longer hangs on anything, and there is no user intervention. It may be a overkill to stop and restart the NAS for any warning and you could fine tune it to look for specific event id's, but we didn't want to bother with it and as it is on it's own VM, we have been able to contain and isolate the service without incident.

    Also note - we decided to re-add the old "MAILLOG" parameter to be used for the NAS startup as the Job Queue was _not_ something that we wanted to infringe with multiple NAS servers. It shouldn't matter either way as the Job Queue basically does the same thing as the dispatcher.

    Hope this helps anyone else running into these fun issues.

    - Scott
    Scott Frappier
    Vice President, Deployment Operations

    Symbiant Technologies, Inc.
    http://www.symbiantsolutions.com
  • Options
    Brett_BarabashBrett_Barabash Member Posts: 9
    Hey Scott, great to hear from you! Things have been going really well, but it's been an interesting year.

    I added your 2 code changes into my code, and I'm fairly sure the SenderExists check will solve their problem with errors from unknown senders.

    The biggest problem they were having involved NAS locking up for long periods of time. Dan Lindström had suggested that this was caused by it constantly logging in and out of CDO. Here's what worked for me:

    Changes to codeunit 5064 RunEMailLogging() trigger:
    RMSetup.TESTFIELD("Storage Folder Name");
    IF ISCLEAR(CDOSession) THEN  //added
      Logon;
    
    ...
    
      CDOQueueMessage.Delete;
      CDOQueueMessage := CDOPrevQueueMessage;
    END;
    //Logoff;  //commented out
    

    This way it will only logon if it needs to, and doesn't logoff afterwards. This causes a potential problem if it loses its connection between runs. To get around this, I made the following changes to codeunit 5065:

    Created global variable - ErrorCount, Type int

    Changes to Timer::TimerError() trigger:
    ErrorCount += 1;  //added
    IF ErrorCount = 1 THEN  //added
      EMailLogging.Logon();  //added
    

    Changes to Timer::Timer() trigger:
    EMailLogging.RunEMailLogging; 
    ErrorCount := 0;  //BB added
    

    This code prevents it from repeatedly trying to logon for subsequent errors. If the mail log process runs successfully, the error count is reset and it can try to logon again if needed.

    When NAS shuts down it's bad form to keep the connection open so I attempt to logoff when the application closes. First, a new trigger was added to codeunit 5065:
    Shutdown()
    MESSAGE('Shutting down E-Mail Dispatcher');
    EMailLogging.Logoff();
    

    2 global variables added to codeunit 1:
    EmailDispatcher - Type: Codeunit, SubType: E-Mail Dispatcher
    MailLogRunning - Type: Boolean

    Changes to codeunit 1 NASHandler() trigger:
        CASE Parameter OF
          'MAILLOG':
    //        CODEUNIT.RUN(CODEUNIT::"E-Mail Dispatcher");  //commented out
            BEGIN  //added
              EmailDispatcher.RUN;  //added
              MailLogRunning := TRUE;  //added
            END;  //added
    

    Changes to codeunit 1 CompanyClose() trigger:
    IF GUIALLOWED THEN
      LogInEnd;
    
    IF MailLogRunning THEN  //added
      EmailDispatcher.Shutdown();  //added
    

    They already had an external app that monitors services so I didn't get a chance to try your batch files for that. You should post it to Tips & Tricks, I'm sure others would find it helpful as well.

    Thanks for all your help.

    Brett
Sign In or Register to comment.