Hi Friends,
Further to my discussion I would like you to update few more points.
I have carried out few more tests and different scenarios on FTP receive and Send Handlers.
1. I would be able to replicate the same issue on three different servers and a brand new installation of BizTalk server. So I conclude myself and I strongly consider it’s not an environmental issue.
2. I have captured the per protocol statistics on BizTalk box using netstat –s option, when executing the scenario under working , dehydrated and rehydrated taken place at various stages, the netstat results are as follows. Please do let me know if you feel any info is useful to track and debug.
—————————————————————————————————————————
When all ports are connected and send ports are active no network issue, the all ftp servers are connected
—————————————————————————————————————————
IPv4 Statistics
Packets Received = 1714848
Received Header Errors = 0
Received Address Errors = 10822
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 228
Received Packets Delivered = 1703798
Output Requests = 1684343
Routing Discards = 0
Discarded Output Packets = 20
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0
ICMPv4 Statistics
Received Sent
Messages 61 105
Errors 0 0
Destination Unreachable 5 53
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 4 0
Echos 0 52
Echo Replies 52 0
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics for IPv4
Active Opens = 2856
Passive Opens = 23201
Failed Connection Attempts = 67
Reset Connections = 59
Current Connections = 81
Segments Received = 1679622
Segments Sent = 1661115
Segments Retransmitted = 2121
UDP Statistics for IPv4
Datagrams Received = 24062
No Ports = 167
Receive Errors = 0
Datagrams Sent = 20999
—————————————————————————————————————————
When one of the ftp servers is pulled off from network.
—————————————————————————————————————————
IPv4 Statistics
Packets Received = 2507948
Received Header Errors = 0
Received Address Errors = 15919
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 228
Received Packets Delivered = 2491801
Output Requests = 2455575
Routing Discards = 0
Discarded Output Packets = 20
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0
ICMPv4 Statistics
Received Sent
Messages 91 139
Errors 0 0
Destination Unreachable 5 57
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 4 0
Echos 1 81
Echo Replies 81 1
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics for IPv4
Active Opens = 4121
Passive Opens = 30064
Failed Connection Attempts = 166
Reset Connections = 80
Current Connections = 30
Segments Received = 2456255
Segments Sent = 2421351
Segments Retransmitted = 3264
UDP Statistics for IPv4
Datagrams Received = 35398
No Ports = 204
Receive Errors = 0
Datagrams Sent = 30817
—————————————————————————————————————————
When the disconnected ftp server connected back onto network
————————————————————————————————————————–
IPv4 Statistics
Packets Received = 3581973
Received Header Errors = 0
Received Address Errors = 21777
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 228
Received Packets Delivered = 3559974
Output Requests = 3513948
Routing Discards = 0
Discarded Output Packets = 20
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0
ICMPv4 Statistics
Received Sent
Messages 118 163
Errors 0 0
Destination Unreachable 9 58
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 4 0
Echos 1 104
Echo Replies 104 1
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics for IPv4
Active Opens = 6190
Passive Opens = 50950
Failed Connection Attempts = 218
Reset Connections = 85
Current Connections = 92
Segments Received = 3513307
Segments Sent = 3469019
Segments Retransmitted = 4541
UDP Statistics for IPv4
Datagrams Received = 46513
No Ports = 237
Receive Errors = 0
Datagrams Sent = 40224
———————————————————————————————————————————————————-
3. Somehow on other scenario I gotrid of the issue by creating one more host instance. But after the execution it led so many questions.
I have created a one more host instance and hosted the weak port to process and when I disconnected the server the results are quite appropriate and all message processing was successful on other 2 active ports.
Are there any limitations on opening connections to destination on host instance?
Does disconnected port really creates dependency on ports hosted on same host instance?
My answers are YES. Here I went little further since I was under assumption to take off all weak ports on to one separate host instance but finally I can’t, I have added one independent sub pub integration point. The second send location is on “weak ports host instance” and nothing related first scenario It receives files from different receive location and sends to the different send location.
Again the results are wired due the disconnected port all messages are stopped processing within that host instance and all send ports under that host instance is non functional. As explained as I am having two active ports hosted on one send handler host instance and the third port is hosted on second host send handler host instance along with the new integration point.
The active send are processing still good since all send ports are active within that host instance but due to inactive one on second instance new integration point also non functional.
I have captured the logs at adapter level, end result nothing is written, I have noticed on logs adapter not even opening a connection to ftp servers to process messages. So certainly I do not want to create “1 to 1” send port to and host instance to host the same. I am just leaving this challenge to adapter development team really suspecting how the adapter manages out going connections on ftp adapters? How the inactive connections are managed?
So I can’t take a direction to change my architecture to move weak send ports on different host instance.
4. I have changed the configuration of FTP send port as per the few discussion went on various BizTalk sites.
“QUIT after put” tried this setting, eventually noticed a change in log files adapter terminates the connection after sending a message successfully and noticed the same on FTP server log closing the connection on delivery of every successful message.
Still no use same old story. But this is quite expensive for BizTalk Adapter to establishing connection and closing per each document delivery. Any how this setting is not help for my scenario and issue.
Today I will be working on fine-tuning host advanced properties and Microsoft BizTalk Server 2006 R2 Management Pack, will update you any pro and cons on my later discussion notes.
Thanks,
-Rajesh Gorla.