So...Messages are never in an Active state, only Services which are Ports (well, technically Pipelines) and Orchestrations.

If this is a Two-Way Send Port that's getting stuck, then one possible cause is the channel between the Adapter and the service is not getting closed properly even though the target is receiving and processing the Message.

When you restart the Host Instance, it tries again, and is technically successful.

• Marked as answer by Angie xuMicrosoft contingent staff, Moderator Wednesday, January 28, 2015 3:26 AM

Hi ,

In our production environment, we are facing strange issues for the past 1 week.

Issue 1:

Messages gets stuck up in active state. In our message tracking mechanism ,the status is successfully sent to destination party. The message should not hold up in active state in first place?

If we restart the Host instance, it is creating duplicate and processing it which is creating misssing ICR issue.

Per day message flow-200 messages

Please suggest ?

Kind Regards,

Giri.a

So...Messages are never in an Active state, only Services which are Ports (well, technically Pipelines) and Orchestrations.

If this is a Two-Way Send Port that's getting stuck, then one possible cause is the channel between the Adapter and the service is not getting closed properly even though the target is receiving and processing the Message.

When you restart the Host Instance, it tries again, and is technically successful.

• Marked as answer by Angie xuMicrosoft contingent staff, Moderator Wednesday, January 28, 2015 3:26 AM

So...Messages are never in an Active state, only Services which are Ports (well, technically Pipelines) and Orchestrations.

If this is a Two-Way Send Port that's getting stuck, then one possible cause is the channel between the Adapter and the service is not getting closed properly even though the target is receiving and processing the Message.

When you restart the Host Instance, it tries again, and is technically successful.

• Marked as answer by Angie xuMicrosoft contingent staff, Moderator Wednesday, January 28, 2015 3:26 AM

What is the transport associated with the port where the messages are? One thing you can do is to set the Retry Count on the Port to ZERO.

I have seen cases in case of MQ and file shares where the client-server communication happens over a WAN and the transport level ACK/NAK never make it back resulting in retries and duplicates.

Regards.

Hi ,

Its all related to client Server communication problem were you are not getting Acknowledgment back for your transaction .In this case better option to troubleshoot is to use NetworkMon  on your Environment and see whether with each request made are you getting an Ack back or not .

One done please let me know so that we can assist further if needed .

Thanks

Abhishek

Hi John,

It is one-way static port and  OFTP adapter is being used. As you pointed out, if I restart the Host instance, we are able to successfully process it. It is related EDI transaction, which is generating duplicate ICR which is a cause of concern.

Please help me out>??

Thanks

Hi Shankycheill,

It is one-way static port and  OFTP adapter is being used.

Thanks,

I would suggest you to collect FTP logs by providing Log file name on the send port.

Simultaneously capture logs on the FTP server, this might give us some clue about the issue.

It seems to be some network issue only. Is there any recent change after which this issue surfaced? like security updates etc.

No Prasant. There are no changes . Its an OFTP Adapter which we are using and we are unable to get any hint, so that we can convey that it has to do with OFTP adapter and not code..//

Hi Girish, 

I believe OFTP adapter is not native adapter(in box) for BizTalk Server.

So, is there any logging mechanism in OFTP adapter?

Also, can we connect to the FTP server using some other tool like Filezilla etc. If other 3rd party products are also not able to connect to this server then we can say that its not a BizTalk issue.