Dear all
is it safe to use a single instance (stored in a 'singleton' or static) of ModbusTCPMaster from multiple threads?
Seems to work and is pretty fast, but I couldn't find any confirmation that this is good practice - or if it's more reasonable that every thread uses it's own instance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, it's not thread safe. The connect and disconnect calls cannot be interleaved.
You need to wrap your use of the singleton inside something that manages the connect and discconnect methods.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The idea is to keep a singleton of a connected ModbusTCPMaster around. The connect and disconnect are handled in one place from one thread
If I get you right the read/write methods on a shared and connected ModbusTCPMaster are thread-safe?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't remember all the problems, but remember that the execute() method may have to close and re-open a connection if there is a communications error in the middle of a command.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's correct - if you keep the connect and disconnect methods as part of a startup and tear down then you should be fine.
One word of caution, the Facade package of methods is beguiling in it's simplicity but unfortunately the code in there is extremely brittle and prone to NPE. Make sure you wrap those methods carefully.
This has been greatly improved in v2.0 which will be available as a release candidate soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the confirmation.
'extremely brittle' sounds like 'don't even think about usuing it'...?
What is the best way to do if I get a NPE? disconnect()/connect() or are there any additional steps necessary?
If the Facade-part is no too different in V2 this sounds like a solution: the Facade-methods are exactly what I need - they 'just' need to be stable of course.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
connect/disconnet in a singleton and the rest ist thread-safe: is this also valid for the 'regular' methods?
if the Facade-methods are 'brittle'... what is the recommended way to use simple modbusTCP read/write?
With 'Facade' it looks straigt forward to write e.g. a word (123) to address (word) 100:
// init in singleton - not thread safe
plc = new ModbusTCPMaster(ip); // singleton - not thread safe
plc.connect();
// then in a Thead just something like
plc.writeSingleRegister(100, new SimpleRegister(123));
...plus handling of the Exceptions of course
A hint and/or example (link) of the recommended way would be very much appreciated. thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you! it does compile and works drop-in.
Unfortunately (IMO) you decided to go with log4j - which is almost bigger than j2mod itselfs - and adds another dependency....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all
is it safe to use a single instance (stored in a 'singleton' or static) of ModbusTCPMaster from multiple threads?
Seems to work and is pretty fast, but I couldn't find any confirmation that this is good practice - or if it's more reasonable that every thread uses it's own instance.
No, it's not thread safe. The connect and disconnect calls cannot be interleaved.
You need to wrap your use of the singleton inside something that manages the connect and discconnect methods.
The idea is to keep a singleton of a connected ModbusTCPMaster around. The connect and disconnect are handled in one place from one thread
If I get you right the read/write methods on a shared and connected ModbusTCPMaster are thread-safe?
I don't remember all the problems, but remember that the execute() method may have to close and re-open a connection if there is a communications error in the middle of a command.
That's correct - if you keep the connect and disconnect methods as part of a startup and tear down then you should be fine.
One word of caution, the Facade package of methods is beguiling in it's simplicity but unfortunately the code in there is extremely brittle and prone to NPE. Make sure you wrap those methods carefully.
This has been greatly improved in v2.0 which will be available as a release candidate soon.
SourceForge needs emoji's so I can "++" your comments about the "facade" package being a turd.
Thanks for the confirmation.
'extremely brittle' sounds like 'don't even think about usuing it'...?
What is the best way to do if I get a NPE? disconnect()/connect() or are there any additional steps necessary?
If the Facade-part is no too different in V2 this sounds like a solution: the Facade-methods are exactly what I need - they 'just' need to be stable of course.
connect/disconnet in a singleton and the rest ist thread-safe: is this also valid for the 'regular' methods?
if the Facade-methods are 'brittle'... what is the recommended way to use simple modbusTCP read/write?
With 'Facade' it looks straigt forward to write e.g. a word (123) to address (word) 100:
// init in singleton - not thread safe plc = new ModbusTCPMaster(ip); // singleton - not thread safe plc.connect(); // then in a Thead just something like plc.writeSingleRegister(100, new SimpleRegister(123));...plus handling of the Exceptions of course
A hint and/or example (link) of the recommended way would be very much appreciated. thank you!
v2.0 is now available on Maven Central - you can also get to the new host here https://github.com/steveohara/j2mod for usage info etc.
Thank you! it does compile and works drop-in.
Unfortunately (IMO) you decided to go with log4j - which is almost bigger than j2mod itselfs - and adds another dependency....
That's not entirely accurate: it depends on slf4j, and there are lighter implementations of that interface than log4j.
slf4j is not supported in compact profiles.