RTC Forums

I keep getting this as an Exception result off our server. No errors at the server end are logged, it just trickles through to the client. Initially I thought it was a ThinDAC issue, but I've now ripped out all the ThinDAC code and I'm still getting it. Searching the source libs it seems to be coming from rtcZLib.pas.

The only strange thing is I can't get it to do it under the debugger (Win XP), it only happens when I put it on the server (Win2008 x64), so I suspect it's something to do with either 2008 or the x64 side, but I've no idea what. I did notice ZLib is now at 1.2.5, and RTC seems to use 1.2.3 - grasping at straws really, but you never know...

Steve..

I've just had a look at the implementation of rtcClientModule and rtcServerModule (which are the only places where ZLib is used) and I don't see any way for a Server-side decompression exception to be forwarded to a Client in form of a rtc_Exception result.

Where do you see that exception? Do you have the name of the unit and a line number where it happens?

Best Regards,
Danijel Tkalcec

At the client end I see Result.isType = rtc_Exception and Result.AsString = 'data error'.

I've been trying to simulate it here with a 2008/64 VM (since I can't get at the live box at the moment), and it does happen, but no where near as much as on the live server - maybe 1 in 5 tries I see one, compared to every time. The only thing I see logged on the server is all OK type messages, saying the query executed fine.

N.B. this is with Compression=cMax, if at cNone I haven't managed to get it to fail (on my test VM), it just takes longer to sync

I'll have to try to get the D7 remote debugger going on Win 2008/64 tomorrow and see if I can track it down further...

Steve..

From what I can see in the TRtcServerModule class implementation, the only way you could get the "data error" exception to the Client as rtc_Exception type would be if the exception is raised on the Server side during data compression (not decompression).

When you say that setting "Compression" to "cNone" eliminates the exception, was this change on the rtcServerModule or on rtcClientModule? Compression is separately set for each direction. If you enable compression on rtcServerModule, data sent from the Server to the Client will be compressed. And if you enable compression on rtcClientModule, data sent from Client to the Server will be compressed. If setting "Compression" to "cNone" on rtcServerModule eliminates the problem and the exception is being raised on the Server side, then it is caused by the compression algorithm and not decompression.

Is that what's happening? Is the exception raised during compression on the Server?

Also ... are you using RTC encryption? Can you try changing that setting (enable encryption if you aren't using it, disable it if you are using it) to see if it makes any difference?

It would also be a good idea if you could write "Result.toCode" inside your remote functions "OnExecute" event to a log file and send me the file when you manage to reproduce the exception. If problem is the compression algorithm, the exception will most likely depend on the data being compressed.

As for the solution ...

If there is a bug in the ZLib implementation, it might help to get the latest ZLib files and compile them with the latest C++ Builder compiler. The complete ZLib files ("*.C" and "*.H") are in the RTC SDK package inside the "Lib\ZLib" folder, so that is where you'd need to drop the updated ZLib files. There is a batch file "_CompileBCC.bat" which should already be set up to compile all ZLib files in that folder to OBJ files, so they can be used from Delphi. You will need a command-line version of "C++Builder" to use it (should be part of every RAD Studio install).

Please let me know if you find out more.

Best Regards,
Danijel Tkalcec

I've uploaded compiled ZLib 1.2.5 files (only those required by the RTC SDK) under "RTC SDK PRO Downloads", please let me know if using this ZLib version cures the problem. To use these files, simply unpack them into the "Lib/zlib" folder, then *rebuild* rtcSDK.dpk and your Client and Server projects in Delphi.

Best Regards,
Danijel Tkalcec

The Compression was set to cNone at both ends, though the exception result is only seen when downloading data from the server.

Encryption is enabled, but ForceEncryption is off - so turn off or force on?

Logging Result.toCode - bit of a problem, I already log all exceptions in the OnExecute and none are triggering, plus I always re-raise them to send back to the client with real info about what went wrong...

I'm just trying the latest ZLibs, thanks for that, I don't have BCC installed anywhere here at the moment.

Steve..

Many thanks again Danijel for your off forum support with this one, I think it's fairly clear now that it's not an RTCSDK issue and is more likely a memory manager problem, possibly specific to Windows 2008 Server 64bit, FastMM has solved it for now, though I'll probably pester the NexusDB guys to see if they've any ideas..

Thanks

Steve..

Just FYI, I tracked it down finally to a problem with the new NX Portal code, EurekaLog gave a memory overwrite error:

|0115208A|lbGateSvr.exe|nxpSimpleSharedMem.pas|TnxpSimpleSharedMem|SendString|171[9]

which was a StrPCopy on a buffer 1 character too short....

Steve..

Thank you for your feedback. I'm glad the problem is resolved.

Best Regards,
Danijel Tkalcec