Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:06
    b-abel commented #1631
  • 13:01
    codecov[bot] commented #1651
  • 13:00
    codecov[bot] commented #1651
  • 12:49
    codecov[bot] commented #1622
  • 12:41
    sophokles73 assigned #1247
  • 12:41
    sophokles73 unassigned #1247
  • 12:40
    sophokles73 commented #1631
  • 12:39
    codecov[bot] commented #1631
  • 12:39
    sophokles73 milestoned #1631
  • 12:39
    sophokles73 labeled #1631
  • 12:38
    codecov[bot] commented #1631
  • 12:25
    dejanb commented #1651
  • 12:25
    dejanb commented #1651
  • 12:22
    codecov[bot] commented #1651
  • 12:22
    dejanb synchronize #1651
  • 12:22

    dejanb on update_artemis_and_router

    Add options for VM memory manag… (compare)

  • 12:18
    sophokles73 closed #1655
  • 12:18
    sophokles73 closed #1656
  • 12:18

    sophokles73 on master

    Do not include logback config i… [#1656] Upgrade to vert.x. 3.8.… [#1655] Upgrade Spring to lates… (compare)

  • 12:15
    sophokles73 assigned #1655
Carsten Lohmann
@calohmn
yes, there should be credit there, that's strange.
Steffen Schmid
@YoLieR
Ok thanks anyhow. We will look further into it at a later point and fallback to control for now.
Karthees Kalidass
@kaniyan
@sophokles73 @ctron Would you mind taking a look at this https://github.com/eclipse/hono/issues/1287#issuecomment-552511128 regarding the device connection time.
Kai Hudalla
@sophokles73
Hi community, do we want to do our community call today? Any pressing issues you would like to discuss? Otherwise we can cancel as Dejan is at KubeCon and will probably not participate and Jens seems to be offline for other reasons ...
Thomas Jaeckle
@thjaeckle
Hi Hono devs. I did not find a (documented) way in order to provide a "correlation-id" or "message-id" as header when sending telemetry or events from devices.
Is there no possibility to do this? I would like to use this for a test of a Hono-Ditto integration in order to ensure that messages can be correlated across systems.
Kai Hudalla
@sophokles73
@thjaeckle not sure what you are up to. Do you want a device to include a correlation-id in its telemetry message that it uploads to a protocol adapter and then want that id end up in the downstream AMQP message's correlation-id property?
Thomas Jaeckle
@thjaeckle
yes, or in the "message-id" property which currently also contains some sort of correlating id (but I guess set by an AMQP component)
Kai Hudalla
@sophokles73
what is the purpose of doing that?
Thomas Jaeckle
@thjaeckle
correlating requests sent via telemetry to responses sent back via one-way-commands ;)
even when not doing request-response (which I know is not yet supported): it would be helpful to use same correlation-ids in order to track down errors when using Hono + Ditto in combination
even better when the device can choose a correlation-id (e.g. always with a prefix) in order to e.g. find log entries related to such IDs
Kai Hudalla
@sophokles73
ok, not all protocols support the concept of headers vs body, e.g. in MQTT, such properties would need to be encoded in the topic name. Apart from that, Hono does not (yet) generically support the inclusion of "headers" provided by a device in downstream AMQP messages. A generic approach would most likely only support inclusion in AMQP application-properties. Setting the correlation-id would require the definition of a "special" header that we suppirt on all protocol adapters
It would probably be easier to implement this in the message payload, i.e. introduce a structure that distinguishes between meta info (headers) and payload ...
Thomas Jaeckle
@thjaeckle
ok, I get that - sending headers in the payload is of course possible, I just thought that we could influence the "message-id" which we receive for Hono telemetry messages
Kai Hudalla
@sophokles73
I also wonder if it feasible to define the forwarding of client provided headers in commands as a supported concept. Not sure if we could implement this for all protocols ...
BTW we currently use the presence of a correlation-id in a command message as an indicator that this is in fact a request/response command (instead of a one-way command) ...
Thomas Jaeckle
@thjaeckle
hm, for HTTP custom headers would be really cool as default headers like "content-type" or "ETag" or other caching headers might become really useful
ah, I thougt Hono uses the reply-to header as indication that this is a request/response command
Kai Hudalla
@sophokles73
you are right, of course, we use the reply-to header ... it's getting late
Thomas Jaeckle
@thjaeckle
ok, all good then :)
Kai Hudalla
@sophokles73
Can you open an issue for this in Hono? We can then track this better ...
Thomas Jaeckle
@thjaeckle
sure
Kai Hudalla
@sophokles73
@ctron Hi Jens, IIRC you wanted to set up a Doodle poll for finding a date/time for the IoT Packages call/meeting, right?
Jens Reimann
@ctron
Yes, I did that … everyone voted :D
it is today … 16:00 CET
Kai Hudalla
@sophokles73
Except for me, because I didn't follow the issue closely enough?
Jens Reimann
@ctron
sorry, that may be … I only know that Carsten can't join today, he is out of office IIRC
there is also a calendar with the invite
I did however forget to add this to the homepage.
Kai Hudalla
@sophokles73
no worries, found it ...
Kai Hudalla
@sophokles73
@dejanb Hi Dejan, have you been able to take a look at #1647 ?
Dejan Bosanac
@dejanb
@sophokles73 just briefly ... I plan to work on it tomorrow
Kai Hudalla
@sophokles73
cool
Kai Hudalla
@sophokles73
@ctron @dejanb @calohmn It looks like there is only a single place where we still use code from Google Guava: some toString() methods in the Device Registry helper classes. I wonder if we can remove that dependency altogether from Hono ... WDYT?
Jens Reimann
@ctron
hm … while I like the "ToStringHelper" stuff, guava's dependencies are sometimes tricky, so getting rid of it might be a good idea :+1:
that would be a change for 1.1?
Kai Hudalla
@sophokles73
I guess so. Guava is not part of any of our public APIs AFAIK
Dejan Bosanac
@dejanb
+1
Carsten Lohmann
@calohmn
I'm also for removing it then.
Kai Hudalla
@sophokles73
I will create an issue for it then and assign it to @ctron !?
Dejan Bosanac
@dejanb
@sophokles73 how do you wanna proceed with #1647
I have some fixes, but I doubt I can push them to bsinno
Kai Hudalla
@sophokles73
I can push the branch to eclipse/hono as well. We can then work on it together an create a PR from it. Would that work for you?
Dejan Bosanac
@dejanb
yeah ... sounds perfect
Kai Hudalla
@sophokles73
ok, gimme a minute ...
Dejan Bosanac
@dejanb
so basically I have helm chart running (at least getting started looks ok) and systems tests run but I saw a couple of failures
would love to push this to see how it looks in CI and then continue tweaking it
Kai Hudalla
@sophokles73
ok, I have pushed the branch to eclipse/hono ...
Dejan Bosanac
@dejanb
cheers
Dejan Bosanac
@dejanb
new pr is #1651 as I don't think we can edit the old one
I also rebased the branch, so now is mergable