Petals SE Camel

Logging problem with MONIT activated for SE Camel

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 0.5.0
  • Fix Version/s: 0.5.1
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    Hello,

    We use camel-se with following route:

    from("file:///XXX?noop=true")
    .to("exec:YYY?args=ARGS").process(processor).to("petals://executeSatinMassCommands");

    and this processor implementation :

    StringBuilder strBuilder = new StringBuilder("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
    strBuilder.append("<jaxb:execute xmlns:jaxb=\"http://jaxb.bss.ocb.orange.com/\" xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\">");
    strBuilder.append("<instruction>");
    strBuilder.append("<commande>/bin/bash</commande>");
    strBuilder.append("<args>-c</args>").append("<args>XXX</args>");
    strBuilder.append("</instruction>");
    strBuilder.append("</jaxb:execute>");
    exchange.getOut().setBody(new StreamSource(new StringReader(strBuilder.toString())));

    The camel exec component do its job as the target (InOnly) BC in petals.
    But we get this stack trace in petals.log :

    sample-0 2015/09/29 13:31:12,361 GMT+0200 INFO [Petals.Container.Components.petals-se-camel] : Received an async answer, let's continue our execution for the exchange petals:uid:96559d40-669d-11e5-92e1-080027c8888b
    sample-0 2015/09/29 13:31:12,361 GMT+0200 SEVERE [Petals.Container.Components.petals-se-camel] : null
    java.lang.NullPointerException
            at org.ow2.petals.commons.log.PetalsExecutionContext.putFlowAttributes(PetalsExecutionContext.java:197)
            at org.ow2.petals.camel.se.CamelJBIListener.handleAsyncJBIMessage(CamelJBIListener.java:133)
            at org.ow2.petals.camel.se.CamelJBIListener.onAsyncJBIMessage(CamelJBIListener.java:110)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processInOnlyAsConsumer(MessageExchangeProcessor.java:586)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processAsConsumer(MessageExchangeProcessor.java:407)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.process(MessageExchangeProcessor.java:354)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.run(MessageExchangeProcessor.java:257)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)
    sample-0 2015/09/29 13:31:12,362 GMT+0200 INFO [Petals.Container.Components.petals-se-camel] : Received an async answer, let's continue our execution for the exchange petals:uid:965c7b10-669d-11e5-92e1-080027c8888b
    sample-0 2015/09/29 13:31:12,363 GMT+0200 SEVERE [Petals.Container.Components.petals-se-camel] : null
    java.lang.NullPointerException
            at org.ow2.petals.commons.log.PetalsExecutionContext.putFlowAttributes(PetalsExecutionContext.java:197)
            at org.ow2.petals.camel.se.CamelJBIListener.handleAsyncJBIMessage(CamelJBIListener.java:133)
            at org.ow2.petals.camel.se.CamelJBIListener.onAsyncJBIMessage(CamelJBIListener.java:110)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processInOnlyAsConsumer(MessageExchangeProcessor.java:586)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processAsConsumer(MessageExchangeProcessor.java:407)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.process(MessageExchangeProcessor.java:354)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.run(MessageExchangeProcessor.java:257)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)
    sample-0 2015/09/29 13:31:12,378 GMT+0200 MONIT [Petals.Container.Components.petals-se-camel] : traceCode = 'consumeFlowStepEnd', flowInstanceId = null, flowStepId = null
    sample-0 2015/09/29 13:31:12,379 GMT+0200 MONIT [Petals.Container.Components.petals-se-camel] : traceCode = 'consumeFlowStepEnd', flowInstanceId = null, flowStepId = null

    and no monitoring trace were logged.

    If we force synchronous execution with "to("petals://executeSatinMassCommands?synchronous=true");
    there's no more stack trace, all route is run but no monit log are write too.

    Show
    Hello, We use camel-se with following route:
    from("file:///XXX?noop=true")
    .to("exec:YYY?args=ARGS").process(processor).to("petals://executeSatinMassCommands");
    and this processor implementation :
    StringBuilder strBuilder = new StringBuilder("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
    strBuilder.append("<jaxb:execute xmlns:jaxb=\"http://jaxb.bss.ocb.orange.com/\" xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\">");
    strBuilder.append("<instruction>");
    strBuilder.append("<commande>/bin/bash</commande>");
    strBuilder.append("<args>-c</args>").append("<args>XXX</args>");
    strBuilder.append("</instruction>");
    strBuilder.append("</jaxb:execute>");
    exchange.getOut().setBody(new StreamSource(new StringReader(strBuilder.toString())));
    The camel exec component do its job as the target (InOnly) BC in petals. But we get this stack trace in petals.log :
    sample-0 2015/09/29 13:31:12,361 GMT+0200 INFO [Petals.Container.Components.petals-se-camel] : Received an async answer, let's continue our execution for the exchange petals:uid:96559d40-669d-11e5-92e1-080027c8888b
    sample-0 2015/09/29 13:31:12,361 GMT+0200 SEVERE [Petals.Container.Components.petals-se-camel] : null
    java.lang.NullPointerException
            at org.ow2.petals.commons.log.PetalsExecutionContext.putFlowAttributes(PetalsExecutionContext.java:197)
            at org.ow2.petals.camel.se.CamelJBIListener.handleAsyncJBIMessage(CamelJBIListener.java:133)
            at org.ow2.petals.camel.se.CamelJBIListener.onAsyncJBIMessage(CamelJBIListener.java:110)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processInOnlyAsConsumer(MessageExchangeProcessor.java:586)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processAsConsumer(MessageExchangeProcessor.java:407)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.process(MessageExchangeProcessor.java:354)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.run(MessageExchangeProcessor.java:257)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)
    sample-0 2015/09/29 13:31:12,362 GMT+0200 INFO [Petals.Container.Components.petals-se-camel] : Received an async answer, let's continue our execution for the exchange petals:uid:965c7b10-669d-11e5-92e1-080027c8888b
    sample-0 2015/09/29 13:31:12,363 GMT+0200 SEVERE [Petals.Container.Components.petals-se-camel] : null
    java.lang.NullPointerException
            at org.ow2.petals.commons.log.PetalsExecutionContext.putFlowAttributes(PetalsExecutionContext.java:197)
            at org.ow2.petals.camel.se.CamelJBIListener.handleAsyncJBIMessage(CamelJBIListener.java:133)
            at org.ow2.petals.camel.se.CamelJBIListener.onAsyncJBIMessage(CamelJBIListener.java:110)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processInOnlyAsConsumer(MessageExchangeProcessor.java:586)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.processAsConsumer(MessageExchangeProcessor.java:407)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.process(MessageExchangeProcessor.java:354)
            at org.ow2.petals.component.framework.process.MessageExchangeProcessor.run(MessageExchangeProcessor.java:257)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)
    sample-0 2015/09/29 13:31:12,378 GMT+0200 MONIT [Petals.Container.Components.petals-se-camel] : traceCode = 'consumeFlowStepEnd', flowInstanceId = null, flowStepId = null
    sample-0 2015/09/29 13:31:12,379 GMT+0200 MONIT [Petals.Container.Components.petals-se-camel] : traceCode = 'consumeFlowStepEnd', flowInstanceId = null, flowStepId = null
    and no monitoring trace were logged. If we force synchronous execution with "to("petals://executeSatinMassCommands?synchronous=true"); there's no more stack trace, all route is run but no monit log are write too.
  • Environment:
    Petals 4.3.0-bêta1
    petals-se-camel-0.5.0.zip
    RHEL 6.4 64
  1. jbi.xml
    (1.0 kB)
    Fabrice Scellos
    Tue, 29 Sep 2015 - 13:45:56 +0200
  2. petals.log
    (25 kB)
    Fabrice Scellos
    Tue, 29 Sep 2015 - 13:49:11 +0200
  3. petals_finest.log
    (15.92 MB)
    Fabrice Scellos
    Wed, 30 Sep 2015 - 09:09:45 +0200

Issue Links

Activity

Hide
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 13:45:56 +0200

JBI of camel su

Show
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 13:45:56 +0200 JBI of camel su
Hide
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 13:49:11 +0200

Petals log file with executing se

Show
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 13:49:11 +0200 Petals log file with executing se
Hide
Victor NOËL added a comment - Tue, 29 Sep 2015 - 15:06:48 +0200 - edited

Hi,

It would be simpler with debug logs.

What seems strange to me is that the component "petals-bc-shell" logs invalid MONIT traces: there is missing flow attributes (you can see the flow*Id are null).

That's why it fails after.
I will fix that at the Camel level (checking for missing MONIT traces), but you won't have any meaningful MONIT traces until you fix this "petals-bc-shell" (that is not one of our components .

Edit: I may be wrong, I will investigate more

Show
Victor NOËL added a comment - Tue, 29 Sep 2015 - 15:06:48 +0200 - edited Hi, It would be simpler with debug logs. What seems strange to me is that the component "petals-bc-shell" logs invalid MONIT traces: there is missing flow attributes (you can see the flow*Id are null). That's why it fails after. I will fix that at the Camel level (checking for missing MONIT traces), but you won't have any meaningful MONIT traces until you fix this "petals-bc-shell" (that is not one of our components . Edit: I may be wrong, I will investigate more
Hide
Victor NOËL added a comment - Tue, 29 Sep 2015 - 15:29:36 +0200

Ok, now it's clearer, it is linked to PETALSSECAMEL-9.

The thing is that at first the Camel SE wasn't meant to be used as a BC (i.e., starting new flows of exchange without having one entering first).

I will commit something today and then you can use the development version (which mostly contains bugfixes since version 0.5.0).

Show
Victor NOËL added a comment - Tue, 29 Sep 2015 - 15:29:36 +0200 Ok, now it's clearer, it is linked to PETALSSECAMEL-9. The thing is that at first the Camel SE wasn't meant to be used as a BC (i.e., starting new flows of exchange without having one entering first). I will commit something today and then you can use the development version (which mostly contains bugfixes since version 0.5.0).
Hide
Christophe DENEUX added a comment - Tue, 29 Sep 2015 - 16:49:06 +0200 - edited

In a strict SOA point of view, this use case should be exploded in two parts:

  1. the consumer part that is the file presence should be assumed by a service unit deployed on Petals BC FileTransfer: when the file 'file:///XXX' occurs, the Petals BC FileTransfer will invoke the service provider available on the SE Camel,
  2. the provider part implemented with the SE Camel and embedding the Camel route defined below without the part 'file'.
Show
Christophe DENEUX added a comment - Tue, 29 Sep 2015 - 16:49:06 +0200 - edited In a strict SOA point of view, this use case should be exploded in two parts:
  1. the consumer part that is the file presence should be assumed by a service unit deployed on Petals BC FileTransfer: when the file 'file:///XXX' occurs, the Petals BC FileTransfer will invoke the service provider available on the SE Camel,
  2. the provider part implemented with the SE Camel and embedding the Camel route defined below without the part 'file'.
Hide
Victor NOËL added a comment - Tue, 29 Sep 2015 - 16:57:51 +0200

Ok, normally it should be fixed in https://github.com/petalslink/petals-se-camel/commit/655dc21e506cecab9127e378ab498d6f890fc428

You can either choose to only apply this diff to version 0.5.0 or directly use the development version 0.5.1-SNAPSHOT (which contains various fixes).

Note that it's normal that you don't see any MONIT traces (or that they have null values, not sure... normally there should be the traces but the ids would be null...) because of PETALSSECAMEL-9 as explained before.
The MONIT trace is logged when the Petals provider is executed, so it's not handled by the the Camel SE in your case.
But maybe, if after applying the fix you don't see any MONIT traces, then there is a bug, could you report it (in the Petals CDK project in Jira) in that case? Thanks!

I will look at PETALSSECAMEL-9 in the near future when I have time

Show
Victor NOËL added a comment - Tue, 29 Sep 2015 - 16:57:51 +0200 Ok, normally it should be fixed in https://github.com/petalslink/petals-se-camel/commit/655dc21e506cecab9127e378ab498d6f890fc428 You can either choose to only apply this diff to version 0.5.0 or directly use the development version 0.5.1-SNAPSHOT (which contains various fixes). Note that it's normal that you don't see any MONIT traces (or that they have null values, not sure... normally there should be the traces but the ids would be null...) because of PETALSSECAMEL-9 as explained before. The MONIT trace is logged when the Petals provider is executed, so it's not handled by the the Camel SE in your case. But maybe, if after applying the fix you don't see any MONIT traces, then there is a bug, could you report it (in the Petals CDK project in Jira) in that case? Thanks! I will look at PETALSSECAMEL-9 in the near future when I have time
Hide
Victor NOËL added a comment - Tue, 29 Sep 2015 - 17:00:08 +0200

Note also that if you follow Christophe's advice by separating the service responsible for reading files (with filetransfer) from the service doing the integration (with camel) then the problem of PETALSSECAMEL-9 won't apply to your case then (and actually, you shouldn't even see the bug you just reported!).

Show
Victor NOËL added a comment - Tue, 29 Sep 2015 - 17:00:08 +0200 Note also that if you follow Christophe's advice by separating the service responsible for reading files (with filetransfer) from the service doing the integration (with camel) then the problem of PETALSSECAMEL-9 won't apply to your case then (and actually, you shouldn't even see the bug you just reported!).
Hide
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:34:22 +0200

Hi Victor, Hi Christophe,

I notice christophe's advice and we effectively can do this (BC FT -> SE Camel --> BC).
But i think a strenght of SE Camel is also to be able to consume petals service through a lot of
other protocol (for example, you don't have BC-Hazelcast, it become possible to define one with this SE...). We plan to use this se-camel for EIP integration but also for external protocol integration (our use case with file is also to test these functionnality).

Victor, i see your code modification : to be honest i'll done the same this morning before opening this defect, and i see anothers errors in log file : to be sure, i'll test with your 0.5.1-SNAPSHOT (if you done other modifications...)
I keep you informed.
Regards.

Show
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:34:22 +0200 Hi Victor, Hi Christophe, I notice christophe's advice and we effectively can do this (BC FT -> SE Camel --> BC). But i think a strenght of SE Camel is also to be able to consume petals service through a lot of other protocol (for example, you don't have BC-Hazelcast, it become possible to define one with this SE...). We plan to use this se-camel for EIP integration but also for external protocol integration (our use case with file is also to test these functionnality). Victor, i see your code modification : to be honest i'll done the same this morning before opening this defect, and i see anothers errors in log file : to be sure, i'll test with your 0.5.1-SNAPSHOT (if you done other modifications...) I keep you informed. Regards.
Hide
Victor NOËL added a comment - Tue, 29 Sep 2015 - 17:42:35 +0200

Ok, I would need the logs in debug mode (to see the details of what is happening at the camel level so, FINEST on the components, but also on org.apache.camel), or even better, an example standalone project that illustrates the problems, because it's difficult for me to fix things without actually executing anything.

Thanks!

Show
Victor NOËL added a comment - Tue, 29 Sep 2015 - 17:42:35 +0200 Ok, I would need the logs in debug mode (to see the details of what is happening at the camel level so, FINEST on the components, but also on org.apache.camel), or even better, an example standalone project that illustrates the problems, because it's difficult for me to fix things without actually executing anything. Thanks!
Hide
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:42:47 +0200

Sorry but i know your release maven repo (http://maven.petalslink.com/libs-release/; even if we get petals-se-camel from public repo) but not your snapshots one : is it possible for you to give me its URL to declare it in our nexus's proxy please ?

Show
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:42:47 +0200 Sorry but i know your release maven repo (http://maven.petalslink.com/libs-release/; even if we get petals-se-camel from public repo) but not your snapshots one : is it possible for you to give me its URL to declare it in our nexus's proxy please ?
Hide
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:52:03 +0200

Victor, i send you by mail and extract of maven module (notice some configurations properties). I'll give you details in mail.

Show
Fabrice Scellos added a comment - Tue, 29 Sep 2015 - 17:52:03 +0200 Victor, i send you by mail and extract of maven module (notice some configurations properties). I'll give you details in mail.
Hide
Fabrice Scellos added a comment - Wed, 30 Sep 2015 - 09:09:45 +0200

Finest log with base of project i sended to you yesterday

Show
Fabrice Scellos added a comment - Wed, 30 Sep 2015 - 09:09:45 +0200 Finest log with base of project i sended to you yesterday
Hide
Victor NOËL added a comment - Wed, 30 Sep 2015 - 09:13:39 +0200 - edited

Maven artefacts are now on Maven central for released one, and ow2 for snapshot ones, but I don't think it is documented, we should do it (maven.petalslink.com should not be used anymore).
For now you can find the latest version of the SE Camel there: http://repository.ow2.org/nexus/content/repositories/snapshots/org/ow2/petals/petals-se-camel/

I got your email, I will take a look and see directly with it if I can do something with that, thanks!

Show
Victor NOËL added a comment - Wed, 30 Sep 2015 - 09:13:39 +0200 - edited Maven artefacts are now on Maven central for released one, and ow2 for snapshot ones, but I don't think it is documented, we should do it (maven.petalslink.com should not be used anymore). For now you can find the latest version of the SE Camel there: http://repository.ow2.org/nexus/content/repositories/snapshots/org/ow2/petals/petals-se-camel/ I got your email, I will take a look and see directly with it if I can do something with that, thanks!
Hide
Victor NOËL added a comment - Wed, 30 Sep 2015 - 11:35:04 +0200

Ok so, everything seems to work perfectly (in the constraints of PETALSSECAMEL-9 of course).

I get the following traces when executing your example:
sample-0 2015/09/30 11:39:18,166 GMT+0200 FINEST [Petals.Container.Components.petals-bc-shell] : Process an exchange as PROVIDER with id : petals:uid:1ed2df20-6757-11e5-903f-0090f5fbc23b
sample-0 2015/09/30 11:39:18,169 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepBegin', flowInstanceId = null, flowStepId = null, flowStepInterfaceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepServiceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepOperationName = '{http://jaxb.bss.ocb.orange.com/}execute', flowStepEndpointName = 'ShellServiceSatinMassCommandsPort', flowPreviousStepId = null

followed by

sample-0 2015/09/30 11:39:18,184 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepEnd', flowInstanceId = null, flowStepId = null

It is what is normally expected: there is one service call happening in the bus, to petals-bc-shell, and it begins and then ends.

Show
Victor NOËL added a comment - Wed, 30 Sep 2015 - 11:35:04 +0200 Ok so, everything seems to work perfectly (in the constraints of PETALSSECAMEL-9 of course). I get the following traces when executing your example: sample-0 2015/09/30 11:39:18,166 GMT+0200 FINEST [Petals.Container.Components.petals-bc-shell] : Process an exchange as PROVIDER with id : petals:uid:1ed2df20-6757-11e5-903f-0090f5fbc23b sample-0 2015/09/30 11:39:18,169 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepBegin', flowInstanceId = null, flowStepId = null, flowStepInterfaceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepServiceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepOperationName = '{http://jaxb.bss.ocb.orange.com/}execute', flowStepEndpointName = 'ShellServiceSatinMassCommandsPort', flowPreviousStepId = null followed by sample-0 2015/09/30 11:39:18,184 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepEnd', flowInstanceId = null, flowStepId = null It is what is normally expected: there is one service call happening in the bus, to petals-bc-shell, and it begins and then ends.
Hide
Victor NOËL added a comment - Wed, 30 Sep 2015 - 15:50:24 +0200

FYI, there is a preliminary fix for PETALSSECAMEL-9 and the version 0.5.1 of the Camel SE is going to be released soon with it.

Show
Victor NOËL added a comment - Wed, 30 Sep 2015 - 15:50:24 +0200 FYI, there is a preliminary fix for PETALSSECAMEL-9 and the version 0.5.1 of the Camel SE is going to be released soon with it.
Hide
Christophe DENEUX added a comment - Thu, 1 Oct 2015 - 09:19:55 +0200
Show
Christophe DENEUX added a comment - Thu, 1 Oct 2015 - 09:19:55 +0200 Petals SE Camel 0.5.1 was released. It is available here: http://repository.ow2.org/nexus/content/repositories/public/org/ow2/petals/petals-se-camel/0.5.1/petals-se-camel-0.5.1.zip
Hide
Fabrice Scellos added a comment - Tue, 13 Oct 2015 - 10:17:12 +0200

Hi.
Test done with Petals SE Camel 0.5.1.
There's no more error logged and route is correctly executed but no MONIT log yet.
Maybe petals's version problem (we always use 4.2 version)

Show
Fabrice Scellos added a comment - Tue, 13 Oct 2015 - 10:17:12 +0200 Hi. Test done with Petals SE Camel 0.5.1. There's no more error logged and route is correctly executed but no MONIT log yet. Maybe petals's version problem (we always use 4.2 version)
Hide
Victor NOËL added a comment - Tue, 13 Oct 2015 - 10:23:26 +0200

After discussing with Fabrice, we clarified that it is not a problem with MONIT log but with Camel logs not being outputed in the log file for the current flow.
This is caused by PETALSSECAMEL-9: the flow is initialised just before the message is sent to the bus (and not when the first external event from the camel file component happens), and whatever is happening before that point is internal to Camel and Petals can't know that it has to associate the Camel logs to this very flow.
This is to be expected as the Camel SE is not really meant to be used like this in a SOA context, even though it would be best if we could cope with it.
Discussion should thus continue in PETALSSECAMEL-9 where I will make note of this important point.

Show
Victor NOËL added a comment - Tue, 13 Oct 2015 - 10:23:26 +0200 After discussing with Fabrice, we clarified that it is not a problem with MONIT log but with Camel logs not being outputed in the log file for the current flow. This is caused by PETALSSECAMEL-9: the flow is initialised just before the message is sent to the bus (and not when the first external event from the camel file component happens), and whatever is happening before that point is internal to Camel and Petals can't know that it has to associate the Camel logs to this very flow. This is to be expected as the Camel SE is not really meant to be used like this in a SOA context, even though it would be best if we could cope with it. Discussion should thus continue in PETALSSECAMEL-9 where I will make note of this important point.
Hide
Fabrice Scellos added a comment - Tue, 13 Oct 2015 - 10:59:36 +0200

Yes. And after a quick test with version 4.3, MONIT log are produced. It's just a little problem with the unsupported couple petals 4.2/SE Camel.
Subject close for me. Thanks for you help Victor & Christophe.

Show
Fabrice Scellos added a comment - Tue, 13 Oct 2015 - 10:59:36 +0200 Yes. And after a quick test with version 4.3, MONIT log are produced. It's just a little problem with the unsupported couple petals 4.2/SE Camel. Subject close for me. Thanks for you help Victor & Christophe.

People

Dates

  • Created:
    Tue, 29 Sep 2015 - 13:43:25 +0200
    Updated:
    Tue, 13 Oct 2015 - 10:59:36 +0200
    Resolved:
    Tue, 29 Sep 2015 - 16:57:51 +0200