Closed umashankar1988 closed 3 years ago
Would it be possible to upgrade to version 1.0.41 to verify that the issue still exists?
Sure, Let me try to upgrade and test the same. Will keep you posted.
We upgraded the boncode adapter but the issue remains the same.
Here are the logs after the upgrade of the adapter to 1.0.42
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendHeaders 10 bytes
begin of packet ====>
Type:4
User Data High:0
User Data Low:200
OK
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 40 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:36
<b>requestXML is empty or null</b>
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 4 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:0
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatEndResponse 2 bytes
begin of packet ====>
Type:5
<==== end of packet
2021-04-07 08:53:02 warning Incorrect response received from Tomcat
2021-04-07 08:53:02 warning Empty packet received from tomcat
2021-04-07 08:53:02 Closing Stream
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendHeaders 110 bytes
> Set-Cookie : USERSESSION=305c4f86cd34e1b5c17ad65c83b3af9ad706d406; Path=/
> Content-Type : application/json;charset=UTF-8
begin of packet ====>
Type:4
User Data High:0
User Data Low:200
OK � <USERSESSION=305c4f86cd34e1b5c17ad65c83b3af9ad706d406; Path=/ � application/json;charset=UTF-8
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 42 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:38
<b>requestXML is empty or null</b>
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 4 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:0
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 4 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:0
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 6 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:2
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 4 bytes
begin of packet ====>
Type:3
User Data High:0
User Data Low:0
<==== end of packet
2021-04-07 08:53:02 BonCodeAJP13.TomcatPackets.TomcatEndResponse 2 bytes
begin of packet ====>
Type:5
<==== end of packet
2021-04-07 08:53:02 warning Empty packet received from tomcat
2021-04-07 08:53:02 Closing Stream
@umashankar1988
I am trying to find your request that causes this response. The current information only shows one side of the conversation, the tomcat response, i.e. the text that <b>requestXML is empty or null</b>
. Most likely cause is that Tomcat believes that it has not received a correct request.
Can you share the full conversation. The corresponding request is missing. It should contain the words BonCodeAJP13ForwardRequest
in the log.
What are you trying to do? Do you have code to use to replicate the issue?
@Bilal-S
This our setup ( We have stripped off the host details and IP information from Log)
IIS - Boncode - Tomcat - Application
We are trying to post data in XML format using the POST method. We are calling one API from our web application with the request in XML format. This is the format of the request XML where we replace the INPUTMETADATAXML with the metadata.
<?xml version="1.0" encoding="UTF-8"?><SCHEMATRONVALIDATION><SCANMODE>METADATA</SCANMODE><SCANDETAILS><METADATAXML><![CDATA[INPUTMETADATAXML]]></METADATAXML></SCANDETAILS><VALIDATION>CLASSES</VALIDATION><VALIDATIONPROJECT>METADATAKATALOGEN</VALIDATIONPROJECT></SCHEMATRONVALIDATION>
So, some metadata have a very huge structure for which we get issues. For some metadata, everything works as desired because the structure is very small.
We would not be able to provide the exact code to replicate the issue.
Attached is the log file where we face the issue.
@umashankar1988 I am seeing that the configuration for Tomcat and Boncode are out of sync when it comes to packet size. Tomcat believes the packet-size is 8096 (8KB) while BonCode is using 65500.
This is indicated by Tomcat response chuncks never exceeding 8KB or (8188 bytes on payload):
2021-04-07 08:53:00 BonCodeAJP13.TomcatPackets.TomcatSendBodyChunk 8188 bytes
In short, when BonCode sends packets that are larger than 8KB you are probably experiencing issues with the communication.
I also see that in your first message in this thread you show the server.xml
with this line:
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" connectionTimeout="120000" packetSize="65500" />
Which should in theory drive Tomcat to adopt the correct packet size (65500) but it is not.
Is there a possibility that you may not use the server.xml
as active configuration, or it is in the different directory?
What you can do test:
This is less efficient but may not be an issue for you. Only potential issue is when you have large HTTP headers/Cookies which I don't see for you in log.
A restart may be required.
@Bilal-S
I have removed the configuration from the Boncode settings file and did a restart
. The problem remains the same. I have attached the logs.
<Settings>
<Port>8009</Port>
<Server>localhost</Server>
<MaxConnections>200</MaxConnections>
<LogLevel>4</LogLevel>
<LogDir>D:\GeodataFiles\BonCode</LogDir>
<TomcatConnectErrorURL1>http://msn.com</TomcatConnectErrorURL1>
<FlushThreshold>0</FlushThreshold>
<EnableRemoteAdmin>False</EnableRemoteAdmin>
</Settings>
We are using the server.xml only and it is placed in the tomcat directory.
According to the Boncode Documentation we had done the setting on both boncode and server.xml
You will need to change the Apache Tomcat packetsize attribute on the AJP protocol to correspond to the PacketSize setting. The maximum value possible is 65536 bytes.
@umashankar1988
I am seeing that a HTTP Post
are taking place and data is sent to Tomcat.
However, on some request this is returned by Tomcat <b>requestXML is empty or null</b>
.
It would be helpful to understand what exactly Tomcat believes it receives.
Where there any errors with more specifics in catalina logs?
In previous configuration (with large packetSize) there was a clear correlation between mismatched packet sizes. As soon as a packet with higher size than expected was sent to Tomcat it returned this response.
In the current setup I don't see an obvious reason why Tomcat should barf. The data is transmitted as HTTP post. It is clearly not an empty
or null
state. Could something happen in the processing of the HTTP post on the target servlet?
Other Questions:
During the restart, did you restart Tomcat?
Then IIS?
The error: Unable to write data to the transport connection:
would normally happen when only IIS is restarted and or the connection pool is not cleared.
Another element to check is XML encoding itself.
It looks like the XML is not complete. When I Decode one of your log examples it does not look like the last tag was closed.
I also guessing the XML is human readable format with many Tabs
as indicated by the +
.
Could that be reason tomcat is showing this error.
Can you verify that the client is streaming/uploading the whole XML to IIS.
<gmd:abstract>
++++++++++++<gco:CharacterString>PBR+str+fr+planer,+bestmmelser+och+rttigheter+och+r+en+produkt+sammanstlld+och+tillhandahllen+av+Lantmteriet.+Produkten+redovisar+positionen+fr+och+utbredning+av+ett+urval+av+de+rttigheter,+gemensamhetsanlggningar,+planer+samt+bestmmelser+om+marks+anvndning+som+finns+registrerade+i+textdelen+av+Fastighetsregistrets+allmnna+del.+Bland+annat+innehller+den+de+beslut+om+bestmmelser+som+lnsstyrelserna+fattar+och+r+skyldiga+att+avisera+till+Fastighetsregistret.+Registerkartans+geometrier+har+ingen+rttsverkan.
PBR-produkten+r+i+lnsstyrelsernas+lagring+uppdelad+per+detaljtyp+(plantyp,+bestmmelsetyp+etc)+varfr+det+finns+en+lng+rad+PBR-skikt+att+tillg.+
Lantmteriet+tillhandahller+hela+PBR-p
In the above case the closing tags should at least have </gco:CharacterString></gmd:abstract>
which I cannot find.
Hi Bilal,
We were able to resolve the issue by doing the following steps
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" packetSize="65500" maxPostSize="8388608" />
Restarted all the services IIS , BONCODE, TOMCAT and were able to make the same work.
Thank you for your help.
Glad you were able to resolve.
We are using Boncode version 1.0.36 and we are facing an issue in updating xml file. We get the following errors requestXML is empty or null when updating the XML file. Tomcat version is 8.0.45 and IIS version 10.0.14393 and Windows 2016.
Please find the boncode settings file and tomcat server.xml. Also, attached is the log file containing the error. Could you guys help us find out what can be the possible cause or a workaround to fix this issue?
Boncode setting
Tomcat server.xml
Boncode logs
Tomcat logs