What's the differents between error and fault?

[fgardes]

If I understand:
1- a fault into an exchange throw a Consumer or a Provider problem : the actors can't dialog correctly. So the exchange status is Active if I throw a fault. It will be done by the partner for each mep. It's a JBI specification.
Are you agree with this?
2-an error into an exchange throw a PEtALS problem : the ESB can't dialog correctly. So the exchange status is Error if I throw an error. It's a PEtALs specification.
Are you agree with this too?
3-And the exchange will be done by the partner for each mep? Or it's finished and the message will be to the Error status forever, never switch to Done status? It persists forever? The monitoring will see it forever active too?

You can easily understand my questions if I say you that I can have thousands and thousands exchanges on Error status active into my pattern, and wouldn't like crash the component, but do something for a great issue

[rnaudin]

Theoretically,
-A fault is a problem at the business level, you are offering a service that transform something? If this service failed to get the entire data it expects to transform but just a partial part, it will raise a Fault, a fault described in the service contract (WSDL). Thus the consumer can treat the fault at it business level too. This kind of exchange is possible inall pattern except InOnly
-In opposite, a consumer can THEORETICALLY get a response from the service it has invoked, and failed to treat it at its business level, so it can sent ack a Fault to the provider, which will handle it at its business level. It is possible in the pattern OptionalInOut, but i don't know any PEtALS component using it, as the Fault can be describe only in the WSDL, which is exposed by the provider and not the consumer, so the consumer must fill a fault DYNAMICALLY according to the provider's WSDL...it's quite complex.

-An error it's a technical error, it is conveys in status or acknowledgement message. A technical error means that the either the JBI container failed to transmit the exchange to the target component, either the target component failed to handle the message up to its business logic (orchestration, transformation, external transport...).

A message is terminated once it has fullfilled the steps of its patterns.
The steps for each pattern are described in the JBI specification section 5.4.2.

A trick is done for one pattern, the InOut pattern. A provider of this pattern is not allowed to return an ack (Done or Error) to the consumer. But it is not forbidden to set an error to a Message Exchange. So when the provider set an error, this error is transformed by default in a generic Fault.

FYI,
An optimization is possible to do it the PEtALS container to avoid to convey the acknowledgement status.
When a CDK component is configured to ignore the ACK and ERROR status, it can set to the message exchange its handled a property org.ow2.petals.messaging.provider.noack or org.ow2.petals.messaging.consumer.noack (configurable in SUs), to tell to the PEtALS container to not convey back the status (ack) message. It avoids unnecessary traffic.

[alouis]

Roland, why did you say ? :
A trick is done for one pattern, the InOut pattern. A provider of this pattern is not allowed to return an ack (Done or Error) to the consumer. But it is not forbidden to set an error to a Message Exchange. So when the provider set an error, this error is transformed by default in a generic Fault.


The provider can set ERROR status when it receives an exchange, the CDK must not transform it as a Fault !!!
An ERROR status can be set at any time (or maybe I missed something in the spec)

[rnaudin]

Maybe you missed something in the specs OR there is a mistake in the spec on that particular pattern.