Difference between revisions of "Invalid Binary Header on Replication"
(→Problem) |
m |
||
| Line 63: | Line 63: | ||
.<Interfaces> | .<Interfaces> | ||
.<Interface Name="Default" UID="{4C2EC238-4FB4-434E-8CFF-ED25EEFF1525}"> | .<Interface Name="Default" UID="{4C2EC238-4FB4-434E-8CFF-ED25EEFF1525}"> | ||
| − | .<Documentation><![CDATA[ Service WinFormsDAServerService. This service has been automatically generated using the RODL template you can find in the Templates directory.]]>< | + | .<Documentation><![CDATA[ Service WinFormsDAServerService. |
| + | This service has been automatically generated using the RODL template you can find in the Templates directory.]]>< | ||
''Note that although the error message is the same, the header returned is an XML file containing the service description.'' | ''Note that although the error message is the same, the header returned is an XML file containing the service description.'' | ||
Revision as of 13:13, 12 October 2012
This is a Technical (IT) Helpdesk topic
Contents
Problem
The Aquila Replication software (aqrepl.exe) is unable to connect to the WinCGI app server module located at https://nww.mdsas.nhs.uk/ibid/cgi-bin/aquilaweb.exe/bin.
The error message returned is "Invalid binary header. Either incompatible or not a binary message". This error is generated from the client-side channel component in aqrepl.exe when it does not received the correct format of reply from the app server. It is always followed by the first 500 characters of the actual reply received.
In this case the full error message is:
Error copying replication data to http://10.195.1.71/ibid/cgi-bin/aquilaweb.exe/bin Invalid binary header. Either incompatible or not a binary message. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> .<html xmlns="http://www.w3.org/1999/xhtml"> .<head> .<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> .<title>500 - Internal server error.</title> .<style type="text/css"> .body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} .fieldset{padding:0 15px 10px 15px;} .h1{font-size:2.4em;margin:0;color:#FFF;} .h2{f
(Notice the actual response received is an HTML document entitled 500 - Internal Server Error)
Replicating the Problem
In order to view the problem, one must run aqrepl.exe. It is a console app and should be run through a console window, where if necessary output can be piped to a text file.
The command line is:
aqrepl SOURCE_URI DESTINATION_URI <params>
for example:
aqrepl http://www.bibid.org.uk/cgi-bin/aquilaweb.exe/bin https://nww.mdsas.com/ibid/cgi-bin/aquilaweb.exe/bin /B1 /R1 /V
where:
- /B1 = batch size of 1 record. This will copy only one audit trail record from the source database to the target database
- /R1 = repeat 1 time. So batch size * repeat count = total number of audit trail records to copy in a single run
- /V = verbose output. Outputs progress record counts and a whole host of debug information.
Analysis
Programming
This problem is symptomatic of using an incorrect URI to access the app server. We have seen it occur when the /bin path is omitted from the URI for instance. However the same app server component (AquilaWeb.exe) is in use in other locations (including http://ibid.mdsas.com/cgi-bin/aquilaweb.exe/bin) without this problem occurring. We have also added additional "debug" output to the aqrepl.exe module that confirms the URI to be correct. Moreover, the URI is actually provided by a command line parameter so when running the aqrepl.exe app manually one can provide any URI.
Server Configuration
Indications are that the problem is not programming related, due to the fact that the same app server module is in use successfully in other places. However, there is contradictory evidence in that it is entirely possible to run the AquilaCRS (IBID) desktop application to connect to the app server at nww.mdsas.com. Moreover, the same datatable that is being accessed by the aqrepl program (ILOG_REPL) can be successfully opened and manipulated by the AquilaCRS.exe client program. The significance of this is that the desktop app (aquilacrs.exe) and the replication module (aqrepl.exe) use identical methods of connection.
SSL
Paul Kelly removed SSL from the equation by using the URI http://10.195.1.71/ibid/cgi-bin/aquilaweb.exe/bin. This did not alter the error message, it was still "Invalid Binary Header", but it did alter the header that was returned. Compare:
Error copying replication data to http://10.195.1.71/ibid/cgi-bin/aquilaweb.exe/bin - Invalid binary header. Either incompatible or not a binary message. <?xml version="1.0" encoding="utf-8"?> .<Library Name="AquilaLibrary" UID="{E7D1248E-8205-4255-A2EB-206555CE7403}" Version="3.0"> .<Services> .<Service Name="DataAbstractService" UID="{709489E3-3AFE-4449-84C3-305C2862B348}" Abstract="1"> .<Interfaces> .<Interface Name="Default" UID="{4C2EC238-4FB4-434E-8CFF-ED25EEFF1525}"> .<Documentation><![CDATA[ Service WinFormsDAServerService. This service has been automatically generated using the RODL template you can find in the Templates directory.]]><
Note that although the error message is the same, the header returned is an XML file containing the service description.
