eclipse-hono
HonoReceiverSampler and HonoSenderSampler use Properties in threadStarted() although properties are not yet merged when threadStarted() gets called
HonoReceiverSampler and HonoSenderSampler use Properties in threadStarted() although properties are not yet merged when threadStarted() gets called.
See Warning in JavaDocs of ThreadListener#threadStarted():
WARNING: this is called before any Config test elements are processed, so any properties they define will not have been merged in yet.
If you for example use a property for tenant configuration this property will not be replaced in org.eclipse.hono.jmeter.client.HonoReceiver#createConsumer.
See for example TCPSampler how this gets solved there.
Are you actually experiencing any issues or are you just pointing out a design problem?
I can workaround this issue by not using properties, but actually I consider this as a bug.
Does this problem still exist on master? I have made several changes to the samplers recently ...
Extracting getTenant from vertx thread seems to fix my actual problem https://github.com/eclipse/hono/blob/39f2227be0ac79673d209211deca1633a38f6dcd/jmeter/src/main/java/org/eclipse/hono/jmeter/client/HonoReceiver.java#L86-L100
I still have non-replaced properties in the logs (these properties get retrieved from within vertx thread):
o.e.h.j.c.HonoReceiver: connected to AMQP Messaging Network [${consumer.targetUrl}:${consumer.targetPort}]
To be honest I am not sure if we have just better timing now or if this fixes the problem sustainable. JMeter seems to replace properties again after they were set in the beginning. I don't know if it would be safe to just get all properties in Constructor for example.
The replacement of the tenant property now works fine for me (0.7-M2).
However there is still the glitches reported by @DanielMaier-BSI in the logging.
I think we can consider this fixed for now.
