Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:32

    kaniyan on master

    Add README file with usage exam… (compare)

  • 07:32
    kaniyan closed #2614
  • Apr 19 16:17
    kaniyan edited #2608
  • Apr 19 16:13
    kaniyan edited #2608
  • Apr 19 16:05
    b-abel synchronize #2614
  • Apr 19 16:01
    kaniyan edited #2608
  • Apr 19 16:00
    kaniyan commented #2608
  • Apr 19 15:35
    kaniyan closed #2609
  • Apr 19 15:25
    kaniyan milestoned #2614
  • Apr 19 15:25
    kaniyan labeled #2614
  • Apr 19 15:09
    kaniyan synchronize #2608
  • Apr 19 14:27
    kaniyan synchronize #2609
  • Apr 19 13:30

    kaniyan on master

    Fix for sending commands and re… (compare)

  • Apr 19 13:30
    kaniyan closed #2612
  • Apr 19 13:26
    kaniyan synchronize #2609
  • Apr 19 13:01
    kaniyan synchronize #2612
  • Apr 19 12:35
    kaniyan synchronize #2612
  • Apr 19 10:22
    b-abel review_requested #2614
  • Apr 19 10:22
    b-abel opened #2614
  • Apr 19 09:58
    kaniyan synchronize #2608
Kai Hudalla
@sophokles73
@BobClaerhout Not sure what you are referring to.
Bob Claerhout
@BobClaerhout
how quickly do you want me to provide the PR?
Bob Claerhout
@BobClaerhout
Still have to add tests but the idea is clear and implemented: eclipse/hono#2552
Kai Hudalla
@sophokles73
I's say ASAP if you want it to go into 1.7.0 :-)
Bob Claerhout
@BobClaerhout
tests added as well
Florian Kaltner
@fkaltner

I am trying to build Hono's Quarkus native images on my machine which is macOS based and runs minikube, hence it is a setup with a remote Docker daemon since minikube runs in a Hyperkit VM. Minikube's VM is configured to share the filesystem via NFS with my host machine.

To my knowledge the support for building native images with a remote Docker daemon was implemented with quarkusio/quarkus#14635 which is why I updated Quarkus locally to 1.13.0.CR1.

In addition to that I set the Maven properties quarkus.native.remote-container-build to "true” and quarkus.native.container-runtime to "docker".

With that configuration the build fails with:

[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildRunner] docker start --attach 6b91e26e205f9a6b6bb982dfe829155411eebc39fc5cee1e294895b33c9df802
[hono-adapter-amqp-vertx-quarkus-1.7.0-SNAPSHOT-runner:25]    classlist:   9.758,77 ms,  1,69 GB
[hono-adapter-amqp-vertx-quarkus-1.7.0-SNAPSHOT-runner:25]        setup:     438,75 ms,  1,69 GB
Error: Policy com.oracle.svm.core.genscavenge.CollectionPolicy cannot be instantiated.
com.oracle.svm.core.util.UserError$UserException: Policy com.oracle.svm.core.genscavenge.CollectionPolicy cannot be instantiated.
    at com.oracle.svm.core.util.UserError.abort(UserError.java:68)
    at com.oracle.svm.core.genscavenge.CollectionPolicy.instantiatePolicy(CollectionPolicy.java:68)
    at com.oracle.svm.core.genscavenge.CollectionPolicy.getInitialPolicy(CollectionPolicy.java:55)
    at com.oracle.svm.core.genscavenge.GCImpl.<init>(GCImpl.java:121)
    at com.oracle.svm.core.genscavenge.HeapImpl.<init>(HeapImpl.java:116)
    at com.oracle.svm.core.genscavenge.graal.HeapFeature.afterRegistration(HeapFeature.java:74)
    at com.oracle.svm.hosted.NativeImageGenerator.lambda$setupNativeImage$11(NativeImageGenerator.java:849)
    at com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:70)
    at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:849)
    at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:561)
    at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:476)
    at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1
ssh: Process exited with status 1

I found out that this seems to be a problem with shell escaping (see https://github.com/quarkusio/quarkus/pull/2435#pullrequestreview-237758165).

So, fmpov, this could be solved by making the "docker create" step of the plugin use

-H:InitialCollectionPolicy='com.oracle.svm.core.genscavenge.CollectionPolicy\$BySpaceAndTime'

instead of

-H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy\$BySpaceAndTime

(which is apparently the default)

I tried to set this option by including it in the Maven property quarkus.native.additional-build-args but this leads to the option being present twice in the "docker create" call when the plugin is run. Unfortunately the escaped version is first, which means it is overwritten by the (falsy escaped) default option.

@dejanb I seem to remember that you are involved in Quarkus / work with the Quarkus team. Do you have any hints for solving this?

Dejan Bosanac
@dejanb
@fkaltner I don't have any solutions ready ... I also encountered problems with building against minikube docker, so it'd be good to have this sorted ... Do you know why option is being used twice in the maven property?
16 replies
Kai Hudalla
@sophokles73
@/all I am currently finishing up the support for native Quarkus images which I should be done with very soon. I would then start to prepare the 1.7.0 release. Anything else you want/need to have in there?
Karthees Kalidass
@kaniyan
I don't have anymore items to include in this release.
Carsten Lohmann
@calohmn
nothing from my side
Bob Claerhout
@BobClaerhout
me neither
Abel Büchner-Mihaljević
@b-abel
me neither
Dejan Bosanac
@dejanb
same here
Florian Kaltner
@fkaltner
all good from my side as well
Kai Hudalla
@sophokles73
Ok, then let's use today's community meeting to go through the 1.7.0 project board and finish up before doing the release ...
Abel Büchner-Mihaljević
@b-abel
Unfortunately, I cannot attend today's community meeting.
Carsten Lohmann
@calohmn
@BobClaerhout I've created eclipse/hono#2576 for the issue you mentioned in the call yesterday.
Kai Hudalla
@sophokles73
@/all The issue identified yesterday ^^^ in the community seems to be a show stopper for the 1.7.0 release. We will therefore postpone the 1.7.0 release until this issue has been fixed. Sorry for the delay ...
Karthees Kalidass
@kaniyan
@sophokles73 @calohmn I have created a PR to add Kafka based north bound client implementation to send commands and receive responses. Would you mind taking a look at #2571 and #2583?
Kai Hudalla
@sophokles73
@/all with #2576 being fixed, we seem to be good to go for 1.7.0. The only remaining tasks are #2580 and then updating the release notes. Anything else?
Kai Hudalla
@sophokles73
@/all I will now prepare the 1.6.1 release and start its release build. Speak up now if you need anything else in it ...
Carsten Lohmann
@calohmn
nothing to add from my side
Kai Hudalla
@sophokles73
release build for 1.6.1 is running ...
Kai Hudalla
@sophokles73
@dejanb @calohmn @ctron @kaniyan I have created the release record for 1.7.0 in the PMI (https://projects.eclipse.org/projects/iot.hono/releases/1.7.0). Can you please take a look and update if necessary?
Kai Hudalla
@sophokles73
@/all I will start the 1.7.0 release build shortly ...
Kai Hudalla
@sophokles73
ok, both the 1.6.1 and 1.7.0 artifacts have been deployed and images have been pushed to Docker Hub. for 1.7.0 we also have the Quarkus based JVM and native images available :-)
Abel Büchner-Mihaljević
@b-abel
:tada:
Karthees Kalidass
@kaniyan
I won't be able to attend the community call today.
Bob Claerhout
@BobClaerhout

Hi all, I deployed version 1.7.0 on our test cluster and I'm currently running into an issue when trying to send commands. The command router generates following output when trying to send a command to a device via a gateway:

Caused by: java.util.concurrent.CompletionException: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=2590 returned server error (status=0x85): java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [hono, RolePrincipal{name='adapter'}, InetAddressPrincipal [address=10.240.0.114/10.240.0.114]]' lacks 'BULK_READ' permission

Any ideas?

Bob Claerhout
@BobClaerhout
Should this be changed in the helm deployment. When I look on https://github.com/eclipse/packages/blob/c7ef5cadfbc9838b5fcc3d58c57661b95f9805fa/charts/hono/config/infinispan/hono-data-grid.xml#L14 I see that the adapter only has acces to READ and WRITE. But not to BULK_READ
Bob Claerhout
@BobClaerhout
So, when I add the BULK_READ permission to the role "adapter", it works again.
Created a new PR in the packages project: eclipse/packages#217
Kai Hudalla
@sophokles73
@BobClaerhout Thanks for the PR. Did you experience this error with earlier versions as well when using Infinispan?
Bob Claerhout
@BobClaerhout
no, I did not. We upgraded from hono 1.5.4 to 1.7.0 all at once and this issue popped up
Kai Hudalla
@sophokles73
But did you also use the Infinispan data grid with 1.5.4?
Bob Claerhout
@BobClaerhout
yes, I did
Kai Hudalla
@sophokles73
That's interesting because the Infinispan (minor) version used for the example grid did not change between 1.5.4 and 1.7.0. We only updated the Infinispan client used in the Command Router service from 10.1 to 11.0 and there is no mentioning of additional authorities being required.
@calohmn Did we introduce any new way of retrieving data from the data grid in Command Router which might require the BULK_READ authority in Infinispan?
Bob Claerhout
@BobClaerhout
I used exactly the same config to deploy 1.5.4 and 1.7.0. No changes in the config and using the datagrid example deploy
Carsten Lohmann
@calohmn
that's interesting indeed. I don't know of any corresponding changes in Hono regarding cache access. In general, we explicitly avoided the cache operations associated with BULK_READ (keySet, values, entrySet, query). I'm having a closer look.
Carsten Lohmann
@calohmn
I could reproduce it - only happens for a device with one or more "via" entries. In that case there is actually a "getAllAsync(Set<?> keys)" cache operation getting invoked, which seems to require BULK_READ. @BobClaerhout Thanks for the PR, it's merged now. I'm still wondering about this not having occurred in your previous setup. Did you use the file-based device-registry with 1.5.4?
Bob Claerhout
@BobClaerhout
no, I used the mongoDb based device registry. The previous setup was the one I used to found out the previous issue about restarting the command router
thanks for investigating it further!
Bob Claerhout
@BobClaerhout
I have another question concerning commands. When a command fails for some reason (no subscriben, mapping fails, ...), what should be the correct handling? From what I can see, the message is being released but that only results in retrying the message over and over. Should I add something to the command which prevents this from happening?
Carsten Lohmann
@calohmn
The correct handling depends on your use case, I think. If there should be a subscriber for commands at all times, it would make sense to retry the message to overcome cases where the device is currently reconnecting or where a protocol adapter is being restarted. Some backoff/timeout mechanism makes sense to not do endless retries then of course.
Your were thinking of adding something like a special header to the command so that some kinds of processing failures result in an "accepted" outcome to be returned?
Bob Claerhout
@BobClaerhout
To give you some more insight of what I'm trying to achieve: I'm in the process of setting up command and control automated testing. And in that process I'm making some mistakes. And when I do, the hono mqtt adapter just keeps on retrying the message until I restart the service. I do believe it is handy to retry a message whenever it fails but if that message keeps on failing it doesn't make sense to keep it retrying. It should eventually reject or accept the message imo. It is, however, very use case dependent as you say. I don't have a proposal yet on how to solve this. My first question was: is this expected behaviour?
Carsten Lohmann
@calohmn
Regarding the "released" outcome returned to the northbound application - yes, that's the expected behaviour in case of a device not being subscribed for example ("rejected" would be the outcome for an invalid command message). I don't quite get what you mean by "the hono mqtt adapter just keeps on retrying the message" - do you mean the northbound application again sends the same command message (with same message id?) over and over, and the mqtt adapter tries to send it to the device, but there's no PUBACK from the device for example, so that a "released" status is returned back to the northbound application?
Bob Claerhout
@BobClaerhout
ok, so that is where this issue resides. We are using enmasse in between the northbound application and hono. Aparently, enmasse is redelivering the message. So the solution probably lies in the configuration for that address in Enmasse
Carsten Lohmann
@calohmn
I would configure the command address as the same kind of address as the telemetry address.
Bob Claerhout
@BobClaerhout
Ok, I would need to look into that. Thanks for assistance