[jira] [Resolved] (CAMEL-20562) Camel-AWS-Bedrock: Support Mistral AI models
[ https://issues.apache.org/jira/browse/CAMEL-20562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20562. -- Resolution: Fixed > Camel-AWS-Bedrock: Support Mistral AI models > > > Key: CAMEL-20562 > URL: https://issues.apache.org/jira/browse/CAMEL-20562 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20562) Camel-AWS-Bedrock: Support Mistral AI models
[ https://issues.apache.org/jira/browse/CAMEL-20562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833982#comment-17833982 ] Andrea Cosentino edited comment on CAMEL-20562 at 4/8/24 1:09 PM: -- Mistral 7B Instruct - Done. Mistral 8x7B Instruct - Done. Mistral Large - Done. was (Author: ancosen): Mistral 7B Instruct - Done. Mistral 8x7B Instruct - Done. > Camel-AWS-Bedrock: Support Mistral AI models > > > Key: CAMEL-20562 > URL: https://issues.apache.org/jira/browse/CAMEL-20562 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20563) camel-kafka - breakOnFirstError causes thread and memory leaks
[ https://issues.apache.org/jira/browse/CAMEL-20563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834885#comment-17834885 ] Aniket Jadhav commented on CAMEL-20563: --- [~davsclaus] any estimates when 3.22.2 will be release? > camel-kafka - breakOnFirstError causes thread and memory leaks > -- > > Key: CAMEL-20563 > URL: https://issues.apache.org/jira/browse/CAMEL-20563 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.5, 3.22.1 >Reporter: Aniket Jadhav >Priority: Major > Fix For: 3.21.5, 3.22.2, 4.0.5, 4.4.2, 4.5.0 > > Attachments: KafkaHeartBeatLeakThread.PNG, > heartbeat-threading-problem.zip > > > This has got fixed in > [CAMEL-16857|https://issues.apache.org/jira/browse/CAMEL-16857]. But Facing > same issue with 3.18.5, is it reintroduced at some point? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20655) camel-core - Uptime is that accurate on shutdown
[
https://issues.apache.org/jira/browse/CAMEL-20655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834850#comment-17834850
]
Otavio Rodolfo Piske commented on CAMEL-20655:
--
Hey Claus, I tried reproducing the problem, but I was unable to:
{code:java}
2024-04-07 18:42:53.140 INFO 2225288 --- [ownCamelContext]
el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (Foo)
shutdown in 35ms (uptime: 4h0m or 14402348 milliseconds in total)
{code}
Did this happen on your laptop or a desktop?
I'm wondering if what you experienced could be because, at some point, the
system entered sleep mode. If you were running this on your laptop, this could
have been the case.
Java's
[nanoTime|https://github.com/openjdk/jdk/blob/d1aad71209092013a89b3b85a258dd4d2e31224a/src/hotspot/os/posix/os_posix.cpp#L1412]
is implemented on top of
[clock_gettime(CLOCK_MONOTONIC)|https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html]
on Linux and
[mach_absolute_time|https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time]
on macOS (both of which do not increment while the system is asleep/suspended.
> camel-core - Uptime is that accurate on shutdown
>
>
> Key: CAMEL-20655
> URL: https://issues.apache.org/jira/browse/CAMEL-20655
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
>
> I have an app running locally for almost 4 hours, but the uptime logged on
> shutdown says 3h and 18 minutes.
> {code}
> ~/workspace/deleteme ❯ camel run rest.camel.yaml
> 2024-04-05 09:10:56.376 INFO 1874 --- [ main]
> org.apache.camel.main.MainSupport : Apache Camel (JBang) 4.6.0-SNAPSHOT is
> starting
> 2024-04-05 09:10:56.485 INFO 1874 --- [ main]
> org.apache.camel.main.MainSupport : Using Java 17.0.5 with PID 1874.
> Started by davsclaus in /Users/davsclaus/workspace/deleteme
> 2024-04-05 09:10:56.567 INFO 1874 --- [ main]
> apache.camel.main.ProfileConfigurer : The application is starting with
> profile: dev
> 2024-04-05 09:10:57.046 INFO 1874 --- [ main]
> mel.cli.connector.LocalCliConnector : Camel JBang CLI enabled
> 2024-04-05 09:10:57.110 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest) is
> starting
> 2024-04-05 09:10:57.233 INFO 1874 --- [ main]
> .core.spi.resolver.ResolverProvider : Using the default address resolver as
> the dns resolver could not be loaded
> 2024-04-05 09:10:57.312 INFO 1874 --- [ntloop-thread-0]
> .http.vertx.VertxPlatformHttpServer : Vert.x HttpServer started on
> 0.0.0.0:8080
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Routes startup (total:2 rest-dsl:2)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Started route1 (rest-api://api-doc)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Started dummy
> (rest://get:abc:%7Bid%7D)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest)
> started in 601ms (build:0ms init:0ms start:601ms)
> 2024-04-05 09:10:57.713 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : HTTP endpoints summary
> 2024-04-05 09:10:57.714 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : http://0.0.0.0:8080/abc/{id}
> (GET)(accept:application/json produce:application/json)
> 2024-04-05 09:10:57.714 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : http://0.0.0.0:8080/api-doc
> (GET)(produce:application/json,text/yaml)
> ^C2024-04-05 13:02:13.519 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest) is
> shutting down (timeout:10s)
> 2024-04-05 13:02:13.530 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Routes stopped (total:2 rest-dsl:2)
> 2024-04-05 13:02:13.531 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Stopped dummy
> (rest://get:abc:%7Bid%7D)
> 2024-04-05 13:02:13.531 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Stopped route1 (rest-api://api-doc)
> 2024-04-05 13:02:13.537 INFO 1874 --- [ntloop-thread-0]
> .http.vertx.VertxPlatformHttpServer : Vert.x HttpServer stopped
> 2024-04-05 13:02:13.542 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest)
> shutdown in 23ms (uptime:3h18m)
> 2024-04-05 13:02:13.542 INFO 1874 --- [ main]
> org.apache
[jira] [Comment Edited] (CAMEL-20655) camel-core - Uptime is that accurate on shutdown
[
https://issues.apache.org/jira/browse/CAMEL-20655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834850#comment-17834850
]
Otavio Rodolfo Piske edited comment on CAMEL-20655 at 4/8/24 8:56 AM:
--
Hey Claus, I tried reproducing the problem, but I was unable to:
{code:java}
2024-04-07 18:42:53.140 INFO 2225288 --- [ownCamelContext]
el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (Foo)
shutdown in 35ms (uptime: 4h0m or 14402348 milliseconds in total)
{code}
Did this happen on your laptop or a desktop?
I'm wondering if what you experienced could be because, at some point, the
system entered sleep mode. If you were running this on your laptop, this could
have been the case.
Java's
[nanoTime|https://github.com/openjdk/jdk/blob/d1aad71209092013a89b3b85a258dd4d2e31224a/src/hotspot/os/posix/os_posix.cpp#L1412]
is implemented on top of
[clock_gettime(CLOCK_MONOTONIC)|https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html]
on Linux and
[mach_absolute_time|https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time]
on macOS (both of which do not increment while the system is asleep/suspended.
was (Author: orpiske):
Hey Claus, I tried reproducing the problem, but I was unable to:
{code:java}
2024-04-07 18:42:53.140 INFO 2225288 --- [ownCamelContext]
el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (Foo)
shutdown in 35ms (uptime: 4h0m or 14402348 milliseconds in total)
{code}
Did this happen on your laptop or a desktop?
I'm wondering if what you experienced could be because, at some point, the
system entered sleep mode. If you were running this on your laptop, this could
have been the case.
Java's
[nanoTime|https://github.com/openjdk/jdk/blob/d1aad71209092013a89b3b85a258dd4d2e31224a/src/hotspot/os/posix/os_posix.cpp#L1412]
is implemented on top of
[clock_gettime(CLOCK_MONOTONIC)|https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html]
on Linux and
[mach_absolute_time|https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time]
on macOS (both of which do not increment while the system is asleep/suspended.
> camel-core - Uptime is that accurate on shutdown
>
>
> Key: CAMEL-20655
> URL: https://issues.apache.org/jira/browse/CAMEL-20655
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
>
> I have an app running locally for almost 4 hours, but the uptime logged on
> shutdown says 3h and 18 minutes.
> {code}
> ~/workspace/deleteme ❯ camel run rest.camel.yaml
> 2024-04-05 09:10:56.376 INFO 1874 --- [ main]
> org.apache.camel.main.MainSupport : Apache Camel (JBang) 4.6.0-SNAPSHOT is
> starting
> 2024-04-05 09:10:56.485 INFO 1874 --- [ main]
> org.apache.camel.main.MainSupport : Using Java 17.0.5 with PID 1874.
> Started by davsclaus in /Users/davsclaus/workspace/deleteme
> 2024-04-05 09:10:56.567 INFO 1874 --- [ main]
> apache.camel.main.ProfileConfigurer : The application is starting with
> profile: dev
> 2024-04-05 09:10:57.046 INFO 1874 --- [ main]
> mel.cli.connector.LocalCliConnector : Camel JBang CLI enabled
> 2024-04-05 09:10:57.110 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest) is
> starting
> 2024-04-05 09:10:57.233 INFO 1874 --- [ main]
> .core.spi.resolver.ResolverProvider : Using the default address resolver as
> the dns resolver could not be loaded
> 2024-04-05 09:10:57.312 INFO 1874 --- [ntloop-thread-0]
> .http.vertx.VertxPlatformHttpServer : Vert.x HttpServer started on
> 0.0.0.0:8080
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Routes startup (total:2 rest-dsl:2)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Started route1 (rest-api://api-doc)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Started dummy
> (rest://get:abc:%7Bid%7D)
> 2024-04-05 09:10:57.712 INFO 1874 --- [ main]
> el.impl.engine.AbstractCamelContext : Apache Camel 4.6.0-SNAPSHOT (rest)
> started in 601ms (build:0ms init:0ms start:601ms)
> 2024-04-05 09:10:57.713 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : HTTP endpoints summary
> 2024-04-05 09:10:57.714 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : http://0.0.0.0:8080/abc/{id}
> (GET)(accept:application/json produce:application/json)
> 2024-04-05 09:10:57.714 INFO 1874 --- [ main]
> t.platform.http.main.MainHttpServer : http:/
[jira] [Updated] (CAMEL-20657) Dead observed while redeploying camel bundle in osgi container
[ https://issues.apache.org/jira/browse/CAMEL-20657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak updated CAMEL-20657: --- Description: We use camel 3.14.7 for our integration scenarios. the integration scenarios are deployed in karaf osgi container. we recently moved from camel 2x to 3x and we observed that if we try to redeploy the integration bundle that is already deployed in osgi container. osgi container first undeploys the existing bundle and redeploys the bundle again with changes. when osgi undeploys the bundle camel tries to stop all the service associated with the bundle that is being undeployed, and we observed that the stop activity is not getting completed and the other threads that are waiting for this undeploy to complete is stuck for ever and goes to deadlock state. I have added the 2 threads stacktrace from the thread dump. one thread waiting for a lock to deploy a new bundle. while the other thread has acquired the lock to undeploy the bundle. was: We use camel 3.14.7 for our integration scenarios. the integration scenarios are deployed in karaf osgi container. we recently moved from camel 2x to 3x and we observed that if we try to redeploy the integration bundle that is already deployed in osgi container. osgi container first undeploys the existing bundle and redeploys the bundle again with changes. when osgi undeploys the bundle camel tries to stop all the service associated with the bundle that is being undeployed, and we observed that the stop activity is not getting completed and the other threads that are waiting for this undeploy to complete is stuck for ever and goes to deadlock state. I have added the 2 threads stacktrace from the thread dump. one thread waiting for a lock to deploy a new bundle. while the other thread has acquired the lock to undeploy the previous version of the same bundle. > Dead observed while redeploying camel bundle in osgi container > -- > > Key: CAMEL-20657 > URL: https://issues.apache.org/jira/browse/CAMEL-20657 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.14.7 >Reporter: Deepak >Priority: Major > Attachments: Thread Dump stack trace.txt > > > We use camel 3.14.7 for our integration scenarios. the integration scenarios > are deployed in karaf osgi container. > we recently moved from camel 2x to 3x and we observed that if we try to > redeploy the integration bundle that is already deployed in osgi container. > osgi container first undeploys the existing bundle and redeploys the bundle > again with changes. > when osgi undeploys the bundle camel tries to stop all the service associated > with the bundle that is being undeployed, and we observed that the stop > activity is not getting completed and the other threads that are waiting for > this undeploy to complete is stuck for ever and goes to deadlock state. > I have added the 2 threads stacktrace from the thread dump. > one thread waiting for a lock to deploy a new bundle. while the other thread > has acquired the lock to undeploy the bundle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20657) Dead observed while redeploying camel bundle in osgi container
Deepak created CAMEL-20657: -- Summary: Dead observed while redeploying camel bundle in osgi container Key: CAMEL-20657 URL: https://issues.apache.org/jira/browse/CAMEL-20657 Project: Camel Issue Type: Bug Components: came-core Affects Versions: 3.14.7 Reporter: Deepak Attachments: Thread Dump stack trace.txt We use camel 3.14.7 for our integration scenarios. the integration scenarios are deployed in karaf osgi container. we recently moved from camel 2x to 3x and we observed that if we try to redeploy the integration bundle that is already deployed in osgi container. osgi container first undeploys the existing bundle and redeploys the bundle again with changes. when osgi undeploys the bundle camel tries to stop all the service associated with the bundle that is being undeployed, and we observed that the stop activity is not getting completed and the other threads that are waiting for this undeploy to complete is stuck for ever and goes to deadlock state. I have added the 2 threads stacktrace from the thread dump. one thread waiting for a lock to deploy a new bundle. while the other thread has acquired the lock to undeploy the previous version of the same bundle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
