|
|
|
Re: jdbc emc problem: "Too many connections" [message #1772641 is a reply to message #1772213] |
Wed, 13 September 2017 13:18 |
|
Hello Gianluigi,
After looking at the driver I can confirm that it uses at most two connections to process the Epsilon data queries. Can you provide further information about your setup? At this point I can only imagine that you are executing multiple transformations at the same time, which eventually open too many connections. This might be unintended, but the connections are dropped only after the ETL execution finishes, so it might be the case that you are starting new executions while the others are finishing.
Another possible cause is that your MySQL configuration has a max. connections settings that is small and hence the error.
Please provides us any further information if you still need help,
Cheers,
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
|
Re: jdbc emc problem: "Too many connections" [message #1772881 is a reply to message #1772643] |
Mon, 18 September 2017 09:57 |
|
Hi Gianluigi,
As stated before the driver only uses two connections... I need to investigate this further. In the mean time, can you pull your DB logs? Maybe we can get some more information on when are the connections created and by whom.
Also (is not related) you can change your "System.out" statements by EOL's native "print" and "println" methods:
...
s.name.println('Rule servicelocation: ');
t.UUID = s.mRID;
...
Can you provide a copy one your console output? Maybe it will provide further insight into how many times the rule executes before it fails.
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
Re: jdbc emc problem: "Too many connections" [message #1778519 is a reply to message #1772881] |
Fri, 15 December 2017 15:27 |
|
Hi,
For future reference, the JDBC driver uses ResourceSets (each of which uses a connection) to provide dynamic collections that are not cached in Java memory but instead accessed directly in the DB. It is good for memory management so the complete DB is not loaded into memory but has the down side that instantiating many collections from the JDBC model will result in "too many connections" errors. As a workaround be sure that in your EOL, ETL, EGL, etc scripts you keep the number of JDBC element access under control. In the OP's case, there was an allInstances access in a transformation rule (pseudo-code):
rule JDBC2SOmething
transform r : Row
to x: X {
x.name = JDBC!Tables.all.select(....);
}
So for each Row in the JDBC model, the "all" operation was invoked. Since each "all" method call created a new connection, then it will result in the mentioned error. If the select operation is static, you could move this to a "pre" block so it is called only once:
pre {
var tables = JDBC!Tables.all.select(....);
}
rule JDBC2SOmething
transform r : Row
to x: X {
x.name = tables.select(...);
}
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
Powered by
FUDForum. Page generated in 0.07469 seconds