Using camel-k getting negative exchange inflight count numbers or why does my route block
Hi,
I am using camel-k 1.3 on a k8s cluster running 1.19 and using
prometheus to capture quarkus metrics from the integrations/pods.
Maybe I just haven't found the correct link, but why can the number of
inflight messages be negative like -50?
Now why am I asking:
The integration blocks after 5 to 10 minutes running or after somewhere
between 2000 and 3000 exchanges completed successfully.
I actually got it to working I just do not know why.
What I had before:
activemq:topic:route1->split->direct:route2->toD:netty:tcp->direct:route3->influxdb
The netty tcp component had 2 endpoints throwing an exception ("reset
peer" and "could not connect") which I caught using doTry()/doCatch().
I am not sure where that process initially actually blocked.
What I have now:
activemq:topic:route1->split->activemq:queue(InOnly):route2->toD:netty:tcp->activemq:queue(InOnly):route3->influxdb
My guess is that the split was actually waiting for all exchanges(split)
to finish. So the problem could be within either netty or the influxdb
component. Fun fact with my working solution the inflight count number
for the netty based route is now at ~-3 after 2 days running.
Does anybody have an idea what I should look for or that the source of
problem is/was?
Thanks,
David
Re: camel-spring-ws: Invalid attribute "Content-Type" in SOAP-ENV:Header element
Hi Claus,
I was able to fix this issue by removing Content-Type header from exchange -
.removeHeaders("Content-Type")
*Thanks*
*Harsh*
On Mon, Mar 8, 2021 at 11:21 AM Harsh Karn wrote:
> Hi,
>
> I'm using camel version 3.7.0 and I've also tried older version 2.25.0.
> The result is the same in both.
>
> Can you give some references where I can look for filter examples?
>
> I tried to look into camel sources but I'm new to java and I'm yet to
> figure out the piece of code which is generating soap envelope messages.
>
> *Thanks*
> *Harsh*
>
Re: camel-spring-ws: Invalid attribute "Content-Type" in SOAP-ENV:Header element
Hi
Thanks for sharing the solution. I created a JIRA to make Camel remove
that header automatically
https://issues.apache.org/jira/browse/CAMEL-16344
On Fri, Mar 12, 2021 at 1:40 PM Harsh Karn wrote:
>
> Hi Claus,
>
> I was able to fix this issue by removing Content-Type header from exchange -
>
> .removeHeaders("Content-Type")
>
> *Thanks*
> *Harsh*
>
>
> On Mon, Mar 8, 2021 at 11:21 AM Harsh Karn wrote:
>
> > Hi,
> >
> > I'm using camel version 3.7.0 and I've also tried older version 2.25.0.
> > The result is the same in both.
> >
> > Can you give some references where I can look for filter examples?
> >
> > I tried to look into camel sources but I'm new to java and I'm yet to
> > figure out the piece of code which is generating soap envelope messages.
> >
> > *Thanks*
> > *Harsh*
> >
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: SMPP Splitting Policy (140+ octets)
Did you try to use 'SubmitMulti' ? just like exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti"); Please refer to the test method sendSubmitMultiSM() in SmppComponentIntegrationTest.java On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell < thomas.odonn...@mdsglobal.com> wrote: > Hi all, > > I'm quite new to this so please bear with me. I've configured my SMPP > component with the following properties. > > bridgeErrorHandler: ERROR > dataCoding: 8 > encoding: UTF-16 > splittingPolicy: ACCEPT > > However, when I send a message over 70 chars, the SMSC server requests it > because the message is over 140 octets. My expectation is that, since > splittingPolicy = ACCEPT, the SMPP server would split the original message > into however many messages under 140 bytes are required so these could be > accepted by the SMSC. > > Am I missing something in the configuration or is my expectation incorrect? > > Some other info: > - Messages under 70 chars are accepted. > - I can't find anything useful in the logs. > - I've tried setting splittingPolicy = REJECT but instead of stopping any > messages over 140 octets, the message is still sent to, and rejected by, > the SMSC. > - I haven't done much testing with other encodings combinations as some > of the messages will contain Thai characters and this is the only encoding > supported by the SMSC provider. > > Thanks in advance, > > Tommy O'Donnell > This email is intended for the person or company named and access by > anyone else is unauthorised. If you are not the person or company named, > please delete this email and notify the sender. The information in this > email, including any attachments, may be confidential or legally privileged > and its unauthorised disclosure, copying, distribution or use is prohibited > and may be unlawful. This email has been sent from MDS Global Ltd, a > registered company incorporated in England and Wales with registered number > 02263085 . The registered office is The Point, 410 Birchwood Boulevard, > Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data > and also the content of email for the purposes of security, ensure > compliance with company policies and staff training. > >
Sample API run with Camel-K does .. almost nothing
Hi everybody, I just tried to run the example under https://github.com/apache/camel-k-examples/tree/master/02-serverless-api After this command E:\camel-k-examples-master\02-serverless-api>kamel run API.java --source test/MinioCustomizer.java --property-file test/minio.properties --open-api=openapi.yaml --dependency=camel-openapi-java --dev Modeline options have been loaded from source files Full command: kamel run API.java --source test/MinioCustomizer.java --property-file test/minio.properties --open-api=openapi.yaml --dependency=camel-openapi-java --dev --open-api=openapi.yaml --dependency=camel-openapi-java integration "api" created nothing more happens. The Minio pod is running. Any ideas about? Best Gerald
