| Author |
Message
|
| scravr |
 Posted: Wed Apr 11, 2012 1:22 am Post subject: Broker V7: EQSL-2-JAVA |
 |
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
HI to all,
On ZLINUX Broker V7 I run the following 2 tests and noticed significant performance degradation on the 2nd test:
1. Call JAVA function from ESQL and pass 3 parameters (as declared on JAVA function prototype).
2. Call JAVA function from ESQL and pass reference to Env. Variable. (as declared on JAVA function prototype).
The JAVA functions are call via ESQL (not JCN).
The 1st function acts directly on prototype parameters, returns integer (0 or 1), and data on a string parameter.
The 2nd function searches for data elements on the env. var. path.
In addition, the 2nd function is part of a complete ESQL-2-JAVA solution with functionality to load+verify properties, check authorization, etc.
When running the 1st function in a long running loop: I get good performance results.
When running the 2nd function in a long running loop performance was very poor.
Can someone explain what broker dose internally when calling java from esql?
Beside function parameters: What other data is passes from esql to java?
When passing env. var. reference: Dose broker COPY it completely or just pass a reference(or pointer)?
Thanks,
MA |
|
| Back to top |
|
 |
| Esa |
| Posted: Wed Apr 11, 2012 1:30 am Post subject: Re: Broker V7: EQSL-2-JAVA |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| scravr wrote: |
The 2nd function searches for data elements on the env. var. path.
|
There are good and bad ways to search a tree. Can you show us the source code of the second function. |
|
| Back to top |
|
|
| scravr |
| Posted: Wed Apr 11, 2012 5:59 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
The 1st test: java function is direct call from esql.
In 2nd test: esql calls generic java function to load properties, valiadtion,... then calls other java functions/services base on value in env. var.
main JAVA function:
...
...
MbElement EsqlReq = (MbElement)env.getFirstElementByPath("ESQL/REQUEST/JAVA_SERVICE");
String EsqlSrvcName = EsqlReq.getValueAsString().toLowerCase();
...
...
// get all args and put in array
List <MbElement> EsqlArgs = (List <MbElement>)env.evaluateXPath("ESQL/REQUEST/ESQL_ARGS/*");
String[] localargs = new String[EsqlArgs.size()];
int counter = 0;
for(MbElement element:EsqlArgs) localargs[counter++] = element.getValueAsString();
...
...
// call the requested java function/service and pass localargs
....
....
// return to esql with data from service/function
...
...
the specific java function acts based on localargs.
The basic question is: what passed from esql to java: Reference to env..var. or complete copy of env.var. ? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Apr 11, 2012 6:05 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The environment that is available when calling from ESQL to Java is configurable at the EG level. By default, it is the same environment that is used by the JCNs.
Your scenario #1 seems highly efficient. Your scenario #2 seems highly in-efficient.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Apr 11, 2012 6:35 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| lancelotlinc wrote: |
| Your scenario #2 seems highly in-efficient. |
Yes. Looks like the 'java for ESQL programmers' from Message Broker V6 courses.
| scravr wrote: |
| // call the requested java function/service and pass localargs |
How do you do this, by calling java reflection api?
| scravr wrote: |
| The basic question is: what passed from esql to java: Reference to env..var. or complete copy of env.var. ? |
By reference.
The problem is in your java code. Check this line that repeats several times in your source code:
I don't think it even compiles  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 11, 2012 6:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Broker makes significant effort to reduce the effort to move between the C++ runtime and JVM and ensure that calls and data items are handled as efficiently as possible.
It's not clear that you are calling the same function in both cases. It sounds like it might be the case, though? can you clarify? |
|
| Back to top |
|
|
| scravr |
| Posted: Wed Apr 11, 2012 6:38 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
How can I check/change the defalut?
In case of default, that means both esql+java sharing same env.var. and there is no copy. esql passes a reference, currect?
Then the performence degradation is because of looking/searching in env MbElements, and also probably because of loading properties in each invocation? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 11, 2012 6:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| scravr wrote: |
How can I check/change the defalut?
In case of default, that means both esql+java sharing same env.var. and there is no copy. esql passes a reference, currect?
Then the performence degradation is because of looking/searching in env MbElements, and also probably because of loading properties in each invocation? |
The performance degredation is almost certainly in your XPath expression. |
|
| Back to top |
|
|
| scravr |
| Posted: Wed Apr 11, 2012 6:45 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
these are two diff test cases.
what could be done to change the xpath?
ideas? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 11, 2012 6:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| scravr wrote: |
what could be done to change the xpath?
ideas? |
Make every step in the path as tightly specific as possible.
There are some notes in the info center about using specific qualifiers for each element. This prevents the xpath from expanding the full tree and searching each element at each level for all matches. |
|
| Back to top |
|
|
| scravr |
| Posted: Wed Apr 11, 2012 7:23 am Post subject: |
|
|
Partisan
Joined: 03 Apr 2003
Posts: 391
Location: NY NY USA 10021
|
since each individual java function/service get/set dynamic number of args, esql passes to java just env.var. reference.
then main java function looks at how many MbElements exist and builds localargs accordinglly.
Not interested in building one-at-a-time..... |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Apr 11, 2012 7:49 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| scravr wrote: |
since each individual java function/service get/set dynamic number of args, esql passes to java just env.var. reference.
then main java function looks at how many MbElements exist and builds localargs accordinglly.
Not interested in building one-at-a-time..... |
OK, it seems the problem is not in calling the functions, then.
You should consider passing the functions a List argument instead of an array. But this is my personal preference only.
The best performing way to extract the arguments is not to use XPath, but MbElement navigation methods. Something like this:
| Code: |
MbElement ref = (MbElement)env.getFirstElementByPath("ESQL");
ref = ref.getFirstElementByPath("REQUEST");
ref = ref.getFirstElementByPath("ESQL_ARGS")
ref = ref.getFirstChild();
List list = new ArrayList();
while (null != ref) {
list.add(ref.getValueAsString();
ref = ref.getNextSibling();
}
|
There may be typos or erros in my code sample. I have been writing mainly ESQL for some months now. |
|
| Back to top |
|
|
|
|
