SQL script cause database to lock block

Ignition
41

Thank you.
It is working perfect now:

	from java.lang import Throwable

	tx = system.db.beginNamedQueryTransaction(system.util.getProjectName(),Project.database, timeout=5000)
	
	queryPath = "Select_All"
	
	ds = ""
	#do query
	try:
		ds = system.db.runNamedQuery(queryPath, tx=tx)
	except Exception as e:
		system.perspective.print(str(e))
	except Throwable as t:
		system.perspective.print(str(t))
		system.db.rollbackTransaction(tx)
	else:
	    system.db.commitTransaction(tx)
	finally:
	    system.db.closeTransaction(tx)
	
	self.getChild("Table").props.data = ds
42 
except Exception as e:
		system.perspective.print(str(e))
	except Throwable as t:

You can use e for both of these, the e will only be available inside the except clause if triggered, and I think using e for the error is what you'll typically see in the field/other peoples scripts.

Also, and I guess this doesn't matter as much since you only have one named query, but in cases you have multiple named queries in a row, you probably want to roll back in your except Exception as e clause as well.

1 Like
43

When error happened on Try Block. Code flow does not proceed? (after Finally block below)

44

How do you know it isn't? ds wouldn't have a value if an exception was thrown.

2 Likes
45

My bad - that is right. I got an error after the try block Thanks.

46

When logging error, is there a variable I can print that shows location(component path) of the script where the error came from.

47

No, but utilizing a custom logger, you can have it indicate what ever you need it to indicate.

48

And a custom logger, when called to log something, will include Perspective view and component information as environment labels.

1 Like
49

I don't know if its just me, but this is not so user friendly.
On a push of a button:
image
This is what I get in gateway log:

image
image715×251 9.76 KB

How do I make the life of debug engineer easier?
Where do I tell more details?

50

Look at/click the icons in the right margin of that page. Or use tail --follow on the wrapper log file itself (my preference).

51

I think I am now beginning to understand.

The gateway "log monitor" has a log level "Ranking" settings which is universal (fixed).
It can be as follows:
image

Depending on what is set on this Ranking settings.
your logger command will show or not show.

If your logging method (.info(), .debug() ) are not under the ranking level set on the Log Monitor, it will not show up. (does this mean, its gone forever?)

Where is the Log Level Ranking(who is greater than who) be found?

52

The ranking of log levels is exactly as pictured in that dropdown - trace < debug < info < warn < error < fatal (which we never use in Ignition).

If you log a message in your script, it is logged to the gateway system log (per the logback.xml file in the gateway install directory) as well as output to stdout, which is captured by the 'service wrapper' process and dumped to the wrapper.log automatically rolling journal (which can be configured via the ignition.conf file).

The setting on the gateway webpage only controls what is shown on that particular page.

There are a few rare use cases where an individual logger uses the logger.isTraceEnabled() or isDebugEnabled() methods to check the global state of a particular logger (which is configurable on that page in the settings menu, or via system.util.setLoggingLevel), but that's rare and not the primary action you'd undertake on that page.

Finally, if you're looking to interact with the system_logs.idb, or a diagnostics bundle, or a variety of other file formats Ignition can export that are useful for troubleshooting/diagnostics, may I not-so-humbly plug Kindling, a tool I originally created to help our internal support team that has since been publicly released and semi-officially blessed.

3 Likes
53

Thank you for shedding a light on this.
As its bugging me for sometime now, how logger works.
Finally I can close this.
My only desire is to have a single place, where I can see all my custom message log, inspect if my system has an error or has unnecessary error.

One important question though:

As a developer, how would you read the Gateway Diagnostic Logs, such that to inspect and make sure, there is no loose scripts (errors from old script that was forgotten). also such that there is no critical error. What should I look for?

54

Scanning the logs for errors is as good an approach as any. "Stale" scripts don't really exist - if you change a script's config, the old code will stop firing and the new code will apply [1]. So if you keep seeing errors in the logs, you know you have an active problem; if you don't, then it's either intermittent or it's disappeared entirely. There's no single way to distinguish between the two.

  1. Technically you can have old code stick around, but you have to either try pretty hard or do something pretty wrong, so in practice for 99% of folks it's not an issue. ↩ī¸Ž

55

I now see the benefit of using system.util.getLogger and system.util.setLoggingLevel.
getLogger allows to log different level, and setLoggingLevel allows the enabling which level to log or show.

Is there a way to output the log message to designer console? Is it wise to use logger instead of system.perspective.print() when debugging script and after debugging set logging level to lowest to hide debug messages.