Arbitrary write error on OutStream apparently linked to file size, how to resolve?

We have a communication between system A (.NET handheld device) and system B (NAV) via the Navision Communication Component, writing XML files and transferring them between the two. Everything works fine for a number of requests & responses with usually single digit KB file sizes.

For one particular process system A requests a .CAB file to update our software, which is stored in a blob field of a table in system B. System B then encodes that file in Base64, puts it into an XML file and responds back to system A. The .CAB is currently about 750kb in size, the transferred XML just under 1MB. In our testing environment and with at least one customer, this works just fine. On a different customer however, this process fails and so far we failed to figure out a reason, let alone a solution.

The particular code is as follows, with vDom containing the XML file ready to send:
[...]
vOutMessage:= vInMessage.CreateReply;
vOutStrm:= vOutMessage.GetStream;

vDom.save(vOutStrm);

IF vOutMessage.Send(0) THEN
  vInMessage.CommitMessage;

On running the process at the customer, the NAS returns the following errors:
The stream has returned a write error.
and subsequently
The call to member send failed. SocketBusAdapter.1 returned Socket error.

At first we thought it to be a problem with the Communication Component, but upon debbuging the NAS we found out that it crashes on writing the XmlDom into the OutStream before even trying to send. We experimented a bit with different file sizes and determined that the process keeps failing with 50KB but does indeed work with 5KB. We didn't try anything in between so far because "it's the file size" seems like a valid enough result. Each of these files still worked flawlessly in our testing environment, even a much bigger 10MB file causing no problems whatsoever.

And now we're at a loss. Why is it causing a write error? Why does it seem to be related to the file size and what can we do to increase or avoid that limit? And why is it occuring only at the customer and not in our own environment, try as we might?


Thank you in advance. I sincerely hope someone can point us in the right direction, because this is starting to drive me crazy.


PS: The only search result that came even remotely close to this problem is this one from way back: https://forum.mibuso.com/discussion/2502/problem-with-navision-communication-component . Unfortunately the answers in there didn't help either.

Comments

  • NavNabNavNab Member Posts: 181
    Hello,

    You didn't say which NAV version you use.

    If by any chance it is NAV 2013 or later and if you're sure it is related to the size only then you need to check the instance configuration on the customer environment. Look for for a property called "Max Upload Size". By default it equals 30M.

    The official help says:

    Max Upload Size
    The maximum size of files that can be uploaded to or downloaded from Microsoft Dynamics NAV Server, in megabytes. Use this setting to avoid out-of-memory errors.
  • ChaosDChaosD Member Posts: 4
    Right, my mistake. We're running NAV2009R2 with the Classic Client and are communicating over IIS7. IIS7 does have a similar option, which also should default to 30MB. I haven't had the chance to check on this with the customer since I know about this, but I'd be really surprised if that's set to something else.
    I'll report back when I know more.
  • ChaosDChaosD Member Posts: 4
    Just checked with the customer and as expected they have the same (default) configuration in IIS7. So this shouldn't be causing the problem.

    The thing is, the NAS crashes upon writing into the Outstream before ever getting to send anything. We tried this with debug messages and the one directly after vDom.save(vOutStrm); was the first that failed to appear. Therefore I can't imagine it to be anything server related.

    I'm still expecting OutStream or the 'Navision Communication Component version 2'.OutMessage Automation to be the problem, albeit the customer having the same file version, but I can't find anything I could change to fix the problem.
Sign In or Register to comment.