Contract negotiation loop

[hlange]

Hi,
I have a problem with the sample 4.0. I fixed the issue with keyName like mentioned in the discussions. But this generated new problems because after everything gone through and the file was moved from one directory to a different, the CPU load of one core gone up to 100%.

Because I thought maybe this could be because it was not the newest version I clone the current version. This generated a complete new issue because the negotiation was running in a loop.

Consumer:

Provider:

By running the following command:
curl -X POST -H "Content-Type: application/json" -d @samples/04.0-file-transfer/contractoffer.json "http://localhost:9191/api/negotiation?connectorAddress=http://localhost:8181/api/ids/multipart"

And I added keyName to ConsumerApiController.java

Best regards,
Henrik

[ndr-brt]

Thanks for finding out, here I see two problems:

• the sample 04 was renamed to 04.0 but its README was not updated accordingly (PR samples: Update sample path on README #543 )
• on the consumer side ContractNegotiation REQUESTING state has two meanings:
  • ContractNegotiation created and waiting to be sent to the provider
  • ContractNegotiation sent to the provider and waiting for response

This causes the infinite loop, because every REQUESTING negotiation is sent to the provider, but it should not

[ndr-brt]

I noticed strange behavior into the contract negotiation repositories (stores).
In fact, both of the "production" (I mean "production code", not "production ready") implementations contain this logic:

if (ContractNegotiationStates.UNSAVED.code() == negotiation.getState()) {
            if (ContractNegotiation.Type.CONSUMER.equals(negotiation.getType())) {
                negotiation.transitionRequesting();
            } else {
                negotiation.transitionRequested();
            }
        }

this is dangerous because this kind of domain logic should stay in the domain classes, in this case in ContractNegotiation probably. Otherwise every time someone implement a ContractNegotiationStore should report that logic in their implementation, and that would bring to duplication.

However my proposal is to define an additional state between UNSAVED and REQUESTING called INITIALIZED (or INITIAL, to make it consisted with the TransferProcess one). The negotiations on consumer state in that state will be sent to provider and moved to PROCESSING. That would resolve this bug

[mspiekermann]

closed by #545