Skip to main content
Solved

FSM 6u6- asynchronous run timeout when processing (too) many units per detail row

  • April 30, 2021
  • 1 reply
  • 108 views

Forum|alt.badge.img+8

Hi,

We have been experiencing the following challenge in FSM 6u6, which is dating back to at least FSM 5.5.2.

 

When posting a Shipment or Receipt where there are many unit rows per detail line, even the asynchronous process seems to time out. 

 

Example picture below.

the shipment record has 1 part need, requesting 1728 serialized items to ship

the shipment is generated with 1 shipment_detail row, containing 1728 shipment_unit rows

 

 

When posting this shipment; the system processes asynchronously.

after approximately 5-minutes, the run log updates to “Complete with Errors”.  and performed a rollback because it was simply not able to process the quantity of units.

 

 

 

We know: 

  • If we break the units into multiple shipments. (<1000 per record)  we have no problem
  • If the shipment had multiple shipment_detail lines, each with no more than ~1000 records, they would post…  even if takes much longer than 5 minutes, becuase the processing seems to time itself against individual shipment_detail lines, not the bulk of the shipment record itself.. 
  • This applies to Receiving as well, if the receiving_unit count is too large per any one receiving_detail row. 

 

 

I would like to understand: 

  • Can the time out be updated anywhere?   
  • Is there a setting to prevent the rollback/timeout?
  • Is this intentional  or a bug? 

 

Thank you in advance

-Rudy

 

 

 

Best answer by Kasun Manuranga

Hello Rudy,

Please check for  Timeout values in web.Config specially Distributed Transaction Settings.

Since there are 1728 of serial transactions to process, this may consume more time hence to run more than 5 minutes.

Example below..

     . . . 
    <!--Transaction timeout specified in minutes-->
    <add key="TransactionTimeout" value="60" />
    . . .
</appSettings> 
<DistributedTransactionSettings>
    <!--Maximum transaction time allowed before forcing timeout and abort transaction, specified in seconds (default 300 seconds = 5 minutes) -->
    <TransactionTimeout>300</TransactionTimeout>
</DistributedTransactionSettings>

 

You may do the update in webconfig then the application has to be restarted. Verify for the  behavior after and give your feedback.

 

Best Regards,

Kasun

 

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

1 reply

Kasun Manuranga
Superhero (Employee)
Forum|alt.badge.img+17
  • Superhero (Employee)
  • 148 replies
  • Answer
  • May 3, 2021

Hello Rudy,

Please check for  Timeout values in web.Config specially Distributed Transaction Settings.

Since there are 1728 of serial transactions to process, this may consume more time hence to run more than 5 minutes.

Example below..

     . . . 
    <!--Transaction timeout specified in minutes-->
    <add key="TransactionTimeout" value="60" />
    . . .
</appSettings> 
<DistributedTransactionSettings>
    <!--Maximum transaction time allowed before forcing timeout and abort transaction, specified in seconds (default 300 seconds = 5 minutes) -->
    <TransactionTimeout>300</TransactionTimeout>
</DistributedTransactionSettings>

 

You may do the update in webconfig then the application has to be restarted. Verify for the  behavior after and give your feedback.

 

Best Regards,

Kasun

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings