DS started with Starter creating a huge log file

However, my concern is, even if there is a try-catch block for "line 1", the log file created on "/var/tmp/ds.log" logs this exception 10 times ( (30-10) seconds/ 2 seconds). I think it should not be logging as there is a catch block. Am I missing something here?
Actually, the point that I am trying to make is if the developer has caught the exception (line 2 in the above code snippet), then TANGO should not log this error message, as the developer has already logged in, is what I feel.
What is the LOG.error() function method doing? Remember that stderr gets copied to the parent process stream.

If, as you wrote, the other device takes some time to startup/init, I'm not surprised you get some 10-15 entries in the log.
Agree, no problem with 10-15 entries, but what if the DS will not be alive for another couple of hours because of maintenance or something like that. How do we tackle this scenario because this is the actual scenario at our site.
Can the a/b/x device being stopped as well? If yes, that's a clean and straightforward solution. If not, you design is tight coupling two services that should be loosley coupled. You may want to add a couple of methods to the a/b/x device in order to create/destroy required device proxies as needed, e.g. at any time at runtime instead just during init(). Then, the list of device proxies to be created at startup can be stored as a a/b/x device property; if device a/b/y is supposed to be offline for long time (e.g. several hours? dsya? You have to decide what long time means in your case) just remove it from the property, in order for a/b/x to startup cleanly when restarted.

I have several comments on the code sample you provided:
try {
	AttributeProxy attrProxy = new AttributeProxy("tango://<TANGO_HOST>:10000/a/b/y/attr");  —-> line 1
} catch (DevFailed e) {
	// TODO Auto-generated catch block
	LOG.error(e);    —> line 2
} ….

The AttributeProxy creation will fail if <TANGO_HOST>:10000 database server is not reachable or tango://<TANGO_HOST>:10000/a/b/y device is not defined in <TANGO_HOST>:10000 Tango Database or if there is a syntax error in the provided attribute name, or …?
If the Tango Database server is reachable and the device is defined in this database, the AttributeProxy creation will not fail, even if the device is not running, this should be the most common case. So I would be interested in knowing the exact error you get when the AttributeProxy creation is failing.
Are you trying to get an AttributeProxy on a dynamic attribute?

Your code sample seems too small to really understand what you are trying to achieve.
It does not make sense to just try an AttributeProxy creation in a try/catch block and then not using the newly created AttributeProxy in this try/catch block… It would be good to delete the pointer at some point too (unless you are not using pointers, your provided code is kind of in the middle, using new but affecting this to a non-pointer variable)… But these are details and it is not the most important.

Please provide the error message you get.

About the problem with the log file which is getting too big, if it is a concern to you, you should really try to avoid these cases where there are errors going to the standard error too often. In our institute, we are using cerr only for critical/fatal errors. In the other cases we are using TANGO ERROR_STREAM.
I think these errors you see should not go to the standard error but should rather go to the Tango ERROR_STREAM which is not redirected to the standard error.
This LOG.error method seems to be specific to your institute or your device server and is sending the error message to the standard error.
If I were you, I would use the ERROR_STREAM instead. And when you are debugging your device server and starting it at the command line in a terminal, simply use -v2 option when starting your device server to see the error stream messages.
Another advice: in my institute, we setup our Linux computers to have a dedicated disk partition for /var/log in order to avoid any big trouble in case a log file is getting too big.

I hope this helps a bit.
Kind regards,
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Register or login to create to post a reply.