HeaderFilterStrategy

[Rafael Sainz]

Hello,

I need to modify HttpHeaderfilterStrategy by removing field date filter because 
I use it as header in my camel route.

[cid:image001.png@01D7EB36.EAB104F0]

So, I have initiate a bean to return a new filter strategy...


@Configuration

public class AppConfig{





  @Bean

  public DefaultHeaderFilterStrategy filterStrat2() {

  DefaultHeaderFilterStrategy filterStrat2 = new 
DefaultHeaderFilterStrategy();

  filterStrat2.getOutFilter().remove("date");

  return filterStrat2;

  }

}

That I have configured my https endpoint and add to headerFilterStrategy …

.to("https://{{cevaldom.status-request}}?throwExceptionOnFailure=false=#filterStra2;)

But the filters still applies and ${headers}" log does not return the expected 
“date” header ..

Do you have a Snippets to help me configure this properly in camel?

Thanks

netty requestTimeout issue still present

[Shuker, Carl]

Hello team

I have trawled through what I could and this Jira appears to be related: 
https://issues.apache.org/jira/browse/CAMEL-15195

When using the netty producer configuration option requestTimeout, with the 
latest 3.13.0 version, we are seeing disconnections occur after successful 
responses have been handled.

Removing the requestTimeout from the options solves the disconnection problem 
but causes our application to critically degrade when we fail to get responses.

We were originally using camel version 2.23.2 (using the netty4 component at 
the time) and were not having any issue with the timeout, this only started to 
occur after upgrading to version 2.25.4, at which point I migrated to the 
latest 3.13.0 after seeing that above Jira was marked as resolved in a later 
version.

I enabled trace logging on the NettyProducer and can see that the changes that 
were related to that Jira are being triggered but an exception is being thrown 
that appears to still be related to the timeout handling.

This occurs for both our TCP and HTTP netty configurations, our tcp config for 
example:

.toF("netty:%s?sync=true=#isoDecoder=#isoEncoder=true=#sslContextParameters=%d",
 remoteAddress, requestTimeout)

Stack trace to follow.

Help appreciated
Carl

Stacktrace:

>>>

T17:19:33,920 DEBUG OrchestratorStationSending AS2805 MTI=0800 
k=84001120617193359585705554 DE11=004001 DE70=Logon to remote 
tcp://localhost:9000
T17:19:33,922 TRACE NettyProducer  Pool[active=0, idle=0]
T17:19:34,007 DEBUG NettyProducer  Created new TCP client bootstrap 
connecting to localhost:9000 with options: Bootstrap(BootstrapConfig(group: 
NioEventLoopGroup, channelFactory: 
ReflectiveChannelFactory(NioSocketChannel.class), options: {SO_KEEPALIVE=true, 
CONNECT_TIMEOUT_MILLIS=1, SO_REUSEADDR=true, TCP_NODELAY=true}, handler: 
org.apache.camel.component.netty.DefaultClientInitializerFactory@5c559d48, 
resolver: io.netty.resolver.DefaultAddressResolverGroup@5c4735d0))
T17:19:34,009 TRACE NettyProducer  Requested channel: 
AbstractBootstrap$PendingRegistrationPromise@7572605b(incomplete)
T17:19:34,009 TRACE NettyProducer  activateObject channel request: 
AbstractBootstrap$PendingRegistrationPromise@7572605b(incomplete)
T17:19:34,009 TRACE NettyProducer  Validating connecting channel 
request: AbstractBootstrap$PendingRegistrationPromise@7572605b(incomplete) -> 
true
T17:19:34,010 TRACE NettyProducer  Got channel request from pool 
AbstractBootstrap$PendingRegistrationPromise@7572605b(incomplete)
T17:19:34,051 TRACE NettyProducer  Channel open finished with 
AbstractBootstrap$PendingRegistrationPromise@7572605b(success)
T17:19:34,052 DEBUG NettyProducer  Creating connector to address: 
localhost:9000
T17:19:34,054 DEBUG NettyProducer  Channel: [id: 0xccb5f3f2, 
L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000] writing body: 
AS2805NetworkManagement0800Message[0800 004001]
T17:19:34,137 TRACE NettyProducer  Channel open: [id: 0xccb5f3f2, 
L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000]
T17:19:34,704 TRACE NettyProducer  Operation complete 
DefaultChannelPromise@200d3948(success)
T17:19:34,716 TRACE NettyProducer  Message received: 
AS2805NetworkManagement0810Message[0810 004001]
T17:19:34,717 TRACE NettyProducer  Removing timeout channel as we 
received message
T17:19:34,717 DEBUG NettyProducer  Channel: [id: 0xccb5f3f2, 
L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000] received body: 
AS2805NetworkManagement0810Message[0810 004001]
T17:19:34,719 TRACE NettyProducer  Putting channel back to pool 
[id: 0xccb5f3f2, L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000]
T17:19:34,719 TRACE NettyProducer  passivateObject channel request: 
AbstractBootstrap$PendingRegistrationPromise@7572605b(success)
T17:19:34,758 DEBUG OrchestratorStationReceived 0810 004001 
response code 00
T17:19:34,762  INFO OrchestratorStationStation local online
T17:19:59,397 TRACE NettyProducer  activateObject channel request: 
AbstractBootstrap$PendingRegistrationPromise@7572605b(success)
T17:19:59,397 TRACE NettyProducer  reset the request timeout as we 
activate the channel
T17:19:59,398 TRACE NettyProducer  Validating channel: [id: 
0xccb5f3f2, L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000] -> true
T17:19:59,398 TRACE NettyProducer  passivateObject channel request: 
AbstractBootstrap$PendingRegistrationPromise@7572605b(success)
T17:20:06,404 TRACE NettyProducer  Exception caught at Channel: 
[id: 0xccb5f3f2, L:/127.0.0.1:53272 - R:localhost/127.0.0.1:9000]
io.netty.handler.timeout.ReadTimeoutException: null
T17:20:06,404 DEBUG NettyProducer  Closing channel as an exception 
was thrown from Netty
io.netty.handler.timeout.ReadTimeoutException: null
T17:20:06,413 

Re: BLOCKING: https://camel.apache.org/schema/blueprint/cxf is down

[Andrea Cosentino]

Thanks for the investigation Zoran.

It worths to have a look at our dependencies related to blueprint and aries.

Cheers!

Il giorno lun 6 dic 2021 alle ore 20:39 Zoran Regvart 
ha scritto:

> Hi Andrea, Cameleers,
> I think this might be caused by a change in the way websites are
> served at ASF: in that all websites now redirect from `http` to
> `https`. Notice of this change was sent on the us...@infra.apache.org
> mailing list[1] in October.
>
> Someone on the Zulip chat[2] just mentioned a similar (or identical)
> issue. It could be that the resolver used to fetch the XML schemas
> doesn't support or is not configured to follow redirects. A
> question[3] on Stack Overflow on a similar (or identical) issue, seems
> to point that this was fixed in a newer version of blueprint-core from
> Aries. And that could be related to this issue[4] that was fixed in
> blueprint-core 1.6.2.
>
> zoran
>
> [1] https://lists.apache.org/thread/wqh6f72lnwcjwon2jjdr8zwxp5r9mgb4
> (requires authentication)
> [2]
> https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Camel.20CXF.20issue
> [3]
> https://stackoverflow.com/questions/70239676/blueprint-container-error-on-osgi-bundle-start-up
> [4] https://issues.apache.org/jira/browse/ARIES-1540
>
>
> On Mon, Dec 6, 2021 at 9:21 AM Zoran Regvart  wrote:
> >
> > Hi Andrea,
> > it seems that files from within `/schema/blueprint/cxf` were removed
> > in 2015, I've restored them now[1] and when the website build[2]
> > finishes in 30-40 minutes. They should be available. I don't know if
> > this will fix the issue you're seeing, you did not provide enough
> > details for me to be even remotely certain of that.
> >
> > In general I would advise you not to allow production systems
> > arbitrary access to the Internet and I urge you to migrate to a newer
> > version of Camel, old versions contain known security defects and
> > you'll struggle getting, even commercial, support for them.
> >
> > zoran
> >
> > [1]
> https://github.com/apache/camel-website/commit/315a5a4e26a194771e8deed457f5ebd4ab767097
> > [2]
> https://ci-builds.apache.org/job/Camel/job/Camel.website/job/main/580/
> >
> > On Mon, Dec 6, 2021 at 1:37 AM Andrea Dondoni 
> wrote:
> > >
> > > Hello All,
> > > today we restart our serviceMix live environment but the system was not
> > > restarted.
> > >
> > > The problem is that this namespace
> > > *https://camel.apache.org/schema/blueprint/cxf
> > > * actually is down.
> > >
> > > How can I solve this?
> > >
> > > This is a blocking problem for my company at this moment.
> > >
> > > BR
> > > Andrea
> >
> >
> >
> > --
> > Zoran Regvart
>
>
>
> --
> Zoran Regvart
>

Re: BLOCKING: https://camel.apache.org/schema/blueprint/cxf is down

[Zoran Regvart]

Hi Andrea, Cameleers,
I think this might be caused by a change in the way websites are
served at ASF: in that all websites now redirect from `http` to
`https`. Notice of this change was sent on the us...@infra.apache.org
mailing list[1] in October.

Someone on the Zulip chat[2] just mentioned a similar (or identical)
issue. It could be that the resolver used to fetch the XML schemas
doesn't support or is not configured to follow redirects. A
question[3] on Stack Overflow on a similar (or identical) issue, seems
to point that this was fixed in a newer version of blueprint-core from
Aries. And that could be related to this issue[4] that was fixed in
blueprint-core 1.6.2.

zoran

[1] https://lists.apache.org/thread/wqh6f72lnwcjwon2jjdr8zwxp5r9mgb4
(requires authentication)
[2] 
https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Camel.20CXF.20issue
[3] 
https://stackoverflow.com/questions/70239676/blueprint-container-error-on-osgi-bundle-start-up
[4] https://issues.apache.org/jira/browse/ARIES-1540


On Mon, Dec 6, 2021 at 9:21 AM Zoran Regvart  wrote:
>
> Hi Andrea,
> it seems that files from within `/schema/blueprint/cxf` were removed
> in 2015, I've restored them now[1] and when the website build[2]
> finishes in 30-40 minutes. They should be available. I don't know if
> this will fix the issue you're seeing, you did not provide enough
> details for me to be even remotely certain of that.
>
> In general I would advise you not to allow production systems
> arbitrary access to the Internet and I urge you to migrate to a newer
> version of Camel, old versions contain known security defects and
> you'll struggle getting, even commercial, support for them.
>
> zoran
>
> [1] 
> https://github.com/apache/camel-website/commit/315a5a4e26a194771e8deed457f5ebd4ab767097
> [2] https://ci-builds.apache.org/job/Camel/job/Camel.website/job/main/580/
>
> On Mon, Dec 6, 2021 at 1:37 AM Andrea Dondoni  
> wrote:
> >
> > Hello All,
> > today we restart our serviceMix live environment but the system was not
> > restarted.
> >
> > The problem is that this namespace
> > *https://camel.apache.org/schema/blueprint/cxf
> > * actually is down.
> >
> > How can I solve this?
> >
> > This is a blocking problem for my company at this moment.
> >
> > BR
> > Andrea
>
>
>
> --
> Zoran Regvart



--
Zoran Regvart

Re: Explain camel processing metrics

[Roberto Camelk]

context and route ok!

But, where are the "processor" metrics type?

On Mon, Dec 6, 2021 at 1:39 PM Claus Ibsen  wrote:
>
> There are 3 levels:
>
> context = overall in entire camel application (eg all routes)
> route = for this route only
> processor = individual step in a route
>
>
>
> On Mon, Dec 6, 2021 at 3:28 PM Roberto Camelk
>  wrote:
> >
> > This are the list of all camel-k metrics exposed via
> > quakus-microprofile-metrics component:
> >
> > application_camel_context_exchanges_completed_total{camelContext="camel-1"}
> > 1066.0
> > application_camel_context_exchanges_failed_total{camelContext="camel-1"} 0.0
> > application_camel_context_exchanges_inflight_count{camelContext="camel-1"} 
> > 1.0
> > application_camel_context_exchanges_total{camelContext="camel-1"} 1066.0
> > application_camel_context_externalRedeliveries_total{camelContext="camel-1"}
> >  0.0
> > application_camel_context_failuresHandled_total{camelContext="camel-1"} 0.0
> > application_camel_context_status{camelContext="camel-1"} 3.0
> > application_camel_context_uptime_seconds{camelContext="camel-1"} 10663.917
> > application_camel_exchange_processing_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 0.004094812477
> > application_camel_exchange_processing_one_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 0.09583574292545141
> > application_camel_exchange_processing_five_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 0.09916668595625462
> > application_camel_exchange_processing_fifteen_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 0.09972294310357353
> > application_camel_exchange_processing_min_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 1.000785047
> > application_camel_exchange_processing_max_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 5.006918741
> > application_camel_exchange_processing_mean_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 3.106591560630775
> > application_camel_exchange_processing_stddev_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 0.8468708871173769
> > application_camel_exchange_processing_seconds_count{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 1066.0
> > application_camel_exchange_processing_seconds_sum{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 3239.381399001
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.5",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 3.307709588
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.75",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 3.7298849
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.95",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 4.803145755
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.98",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 4.809673119
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.99",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 4.809673119
> > application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.999",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> > 4.809673119
> > application_camel_route_count{camelContext="camel-1"} 1.0
> > application_camel_route_exchanges_completed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 1066.0
> > application_camel_route_exchanges_failed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 0.0
> > application_camel_route_exchanges_inflight_count{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 1.0
> > application_camel_route_exchanges_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 1066.0
> > application_camel_route_externalRedeliveries_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 0.0
> > application_camel_route_failuresHandled_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> > 0.0
> > 

Re: RabbitMQ set replyTo queue

[V User]

Hi Claus,

It looks like the spring-rabbitmq feature is set up to use the RabbitMQ
"direct reply-to" paradigm (
https://camel.apache.org/components/3.13.x/spring-rabbitmq-component.html#_request_reply),
which is not how the target application is implemented (i.e. it is not
reading from the amq.rabbitmq.reply-to queue or publishing to a
response queue defined by the message header; there's a pre-defined input
queue it reads messages from and a pre-defined output queue it publishes
responses to).

I think I've found what I need with the JMS connector & an exclusive
response queue though (
https://camel.apache.org/components/3.13.x/jms-component.html#_request_reply_over_jms).
Fortunately, the target application is able to support JMS.

-Zoe

On Sat, Dec 4, 2021 at 12:12 AM Claus Ibsen  wrote:

> Hi
>
> Can you try with the spring-rabbitmq component
>
> On Fri, Dec 3, 2021 at 11:38 PM V User  wrote:
> >
> > Hello!
> >
> > I'm new to Camel and setting up my first flow, an adaptor for an existing
> > system with an API that uses RabbitMQ. The API already defines a queue to
> > publish messages to, and a queue where responses will be published back
> to.
> > I'm trying to get Camel to read replies from the existing queue. I
> thought
> > that setting the CamelRabbitmqReplyTo header (
> >
> https://camel.apache.org/components/3.13.x/rabbitmq-component.html#_message_headers
> )
> > on the exchange during a processor call would do it, but it seems that
> > value gets overwritten by the RabbitMQProducer during processing. Is this
> > the intended behavior? Is there a different stage I should be setting it
> on
> > that would catch it post-process or something? I also can't find any
> config
> > option to set a ReplyTo value on the RabbitMQ component or anything like
> > that.
> >
> > For reference, here's my route configuration:
> > from("netty:tcp://{{tcp.host}}:{{tcp.port.number}}?sync=true")
> > .process(m_inboundProcessor)
> > .to("rabbitmq:camel?"
> > + "request-Timeout=3000&"
> > + "connectionFactory=rabbitmqConnectionFactory&"
> > + "queue={{rabbitmq.exchange.routingKey}}&"
> > + "routingKey={{rabbitmq.exchange.routingKey}}&"
> > + "autoDelete=false&"
> > + "allowCustomHeaders=true")
> > .log("Received body: ${body}");
> >
> > And here's the relevant line from m_inboundProcessor:
> > exchange.getIn().getHeaders().put("CamelRabbitmqReplyTo",
> > "apiQueueName");
> >
> > Is extending TemporaryQueueReplyManager to set a standard value for
> replyTo
> > maybe possible?
> >
> > Thanks,
> > Zoe
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Explain camel processing metrics

[Claus Ibsen]

There are 3 levels:

context = overall in entire camel application (eg all routes)
route = for this route only
processor = individual step in a route



On Mon, Dec 6, 2021 at 3:28 PM Roberto Camelk
 wrote:
>
> This are the list of all camel-k metrics exposed via
> quakus-microprofile-metrics component:
>
> application_camel_context_exchanges_completed_total{camelContext="camel-1"}
> 1066.0
> application_camel_context_exchanges_failed_total{camelContext="camel-1"} 0.0
> application_camel_context_exchanges_inflight_count{camelContext="camel-1"} 1.0
> application_camel_context_exchanges_total{camelContext="camel-1"} 1066.0
> application_camel_context_externalRedeliveries_total{camelContext="camel-1"} 
> 0.0
> application_camel_context_failuresHandled_total{camelContext="camel-1"} 0.0
> application_camel_context_status{camelContext="camel-1"} 3.0
> application_camel_context_uptime_seconds{camelContext="camel-1"} 10663.917
> application_camel_exchange_processing_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 0.004094812477
> application_camel_exchange_processing_one_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 0.09583574292545141
> application_camel_exchange_processing_five_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 0.09916668595625462
> application_camel_exchange_processing_fifteen_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 0.09972294310357353
> application_camel_exchange_processing_min_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 1.000785047
> application_camel_exchange_processing_max_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 5.006918741
> application_camel_exchange_processing_mean_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 3.106591560630775
> application_camel_exchange_processing_stddev_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 0.8468708871173769
> application_camel_exchange_processing_seconds_count{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 1066.0
> application_camel_exchange_processing_seconds_sum{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 3239.381399001
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.5",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 3.307709588
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.75",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 3.7298849
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.95",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 4.803145755
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.98",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 4.809673119
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.99",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 4.809673119
> application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.999",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
> 4.809673119
> application_camel_route_count{camelContext="camel-1"} 1.0
> application_camel_route_exchanges_completed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 1066.0
> application_camel_route_exchanges_failed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 0.0
> application_camel_route_exchanges_inflight_count{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 1.0
> application_camel_route_exchanges_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 1066.0
> application_camel_route_externalRedeliveries_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 0.0
> application_camel_route_failuresHandled_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 0.0
> application_camel_route_processing_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 0.0041617396048
> application_camel_route_processing_one_min_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
> 0.09583574292545141
> 

Explain camel processing metrics

[Roberto Camelk]

This are the list of all camel-k metrics exposed via
quakus-microprofile-metrics component:

application_camel_context_exchanges_completed_total{camelContext="camel-1"}
1066.0
application_camel_context_exchanges_failed_total{camelContext="camel-1"} 0.0
application_camel_context_exchanges_inflight_count{camelContext="camel-1"} 1.0
application_camel_context_exchanges_total{camelContext="camel-1"} 1066.0
application_camel_context_externalRedeliveries_total{camelContext="camel-1"} 0.0
application_camel_context_failuresHandled_total{camelContext="camel-1"} 0.0
application_camel_context_status{camelContext="camel-1"} 3.0
application_camel_context_uptime_seconds{camelContext="camel-1"} 10663.917
application_camel_exchange_processing_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
0.004094812477
application_camel_exchange_processing_one_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
0.09583574292545141
application_camel_exchange_processing_five_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
0.09916668595625462
application_camel_exchange_processing_fifteen_min_rate_per_second{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
0.09972294310357353
application_camel_exchange_processing_min_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
1.000785047
application_camel_exchange_processing_max_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
5.006918741
application_camel_exchange_processing_mean_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
3.106591560630775
application_camel_exchange_processing_stddev_seconds{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
0.8468708871173769
application_camel_exchange_processing_seconds_count{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
1066.0
application_camel_exchange_processing_seconds_sum{camelContext="camel-1",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
3239.381399001
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.5",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
3.307709588
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.75",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
3.7298849
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.95",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
4.803145755
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.98",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
4.809673119
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.99",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
4.809673119
application_camel_exchange_processing_seconds{camelContext="camel-1",quantile="0.999",endpointName="quartz://tab?cron=0%2F10+*+*+*+*+%3F",eventType="ExchangeCreatedEvent"}
4.809673119
application_camel_route_count{camelContext="camel-1"} 1.0
application_camel_route_exchanges_completed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
1066.0
application_camel_route_exchanges_failed_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.0
application_camel_route_exchanges_inflight_count{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
1.0
application_camel_route_exchanges_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
1066.0
application_camel_route_externalRedeliveries_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.0
application_camel_route_failuresHandled_total{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.0
application_camel_route_processing_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.0041617396048
application_camel_route_processing_one_min_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.09583574292545141
application_camel_route_processing_five_min_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.09916668595625462
application_camel_route_processing_fifteen_min_rate_per_second{camelContext="camel-1",routeId="MicroProfileMetrics-route-1"}
0.09972294310357353

Re: BLOCKING: https://camel.apache.org/schema/blueprint/cxf is down

[Zoran Regvart]

Hi Andrea,
it seems that files from within `/schema/blueprint/cxf` were removed
in 2015, I've restored them now[1] and when the website build[2]
finishes in 30-40 minutes. They should be available. I don't know if
this will fix the issue you're seeing, you did not provide enough
details for me to be even remotely certain of that.

In general I would advise you not to allow production systems
arbitrary access to the Internet and I urge you to migrate to a newer
version of Camel, old versions contain known security defects and
you'll struggle getting, even commercial, support for them.

zoran

[1] 
https://github.com/apache/camel-website/commit/315a5a4e26a194771e8deed457f5ebd4ab767097
[2] https://ci-builds.apache.org/job/Camel/job/Camel.website/job/main/580/

On Mon, Dec 6, 2021 at 1:37 AM Andrea Dondoni  wrote:
>
> Hello All,
> today we restart our serviceMix live environment but the system was not
> restarted.
>
> The problem is that this namespace
> *https://camel.apache.org/schema/blueprint/cxf
> * actually is down.
>
> How can I solve this?
>
> This is a blocking problem for my company at this moment.
>
> BR
> Andrea



-- 
Zoran Regvart