| Author |
Message
|
| bdaoust |
 Posted: Fri Oct 23, 2015 6:15 am Post subject: Library with one DFDL - BAR File Taking Long Time To Deploy |
 |
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Good morning.
I have one library that has one DFDL. (for CSV output)
The DFDL has about 1,200 elements defined.
It sometimes/always takes over 10 minutes to deploy.
Is it because I have some many elements in the DFDL defined?
The admin watched while I deployed and said there was high CPU usage during the deployment that seemed to be caused by my deployment.
Any ideas of what I may be able to do?
Thanks,
Brian |
|
| Back to top |
|
 |
| timber |
| Posted: Fri Oct 23, 2015 6:20 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Which version of WMB / IIB are you using? Please quote the fix pack level, because it does matter in this case. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 6:39 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Hi timber:
Sorry about that - I should know better to include this:
IBM Integration Toolkit
Version: 9.0.0.2
Build id: 9.0.0.2-20140515-1210 |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Oct 23, 2015 7:20 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| What about runtime fix pack level? |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 7:21 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
I don't think I have the run time on my machine? When I deploy, I need to deploy to a development server.
That is all managed by another group. I can ask though. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 7:31 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
|
| Back to top |
|
|
| timber |
| Posted: Fri Oct 23, 2015 7:44 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Upgrade your *runtime* to 9.0.0.4. You should find that it's roughly twice as fast at deploying DFDL schemas. After the upgrade, please post again and tell us how long it takes. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 7:55 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 23, 2015 8:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bdaoust wrote: |
| Our support team may be reluctant to install a fixpack unless I can provide supporting documentation to match my cause. |
Your support team believe that no improvements are ever made by IBM in any fix pack but it's nothing but bug fixes? What do they think the -f flag is for on the mqsichangebroker command?
The slow deployment doesn't mean there's anything wrong with DFDL handling in v9.0.0.2, and doesn't mean that the perfectly functional v9.0.0.2 process hasn't been improved (and speeded up) in v9.0.0.4.
Also, this by your own admission is a development server. Development servers get fix packs installed. Occasionally demonstrating that the fix pack in question should never be installed anywhere else.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 23, 2015 8:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
That indicates specific errors that were fixed, and does not indicate things like performance tuning or other enhancements.
The release notes may show some additional info.
If you have an issue, and you have a reason to suspect it's fixed in a newer fixpack, then your operators should be willing to at least test it.
Particularly since you can install the FP in a separate directory and run a separate broker on that FP for purposes of testing.
Other than cpu/mem impact, this doesn't interrupt any use of the other broker at the regular FP level.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| timber |
| Posted: Fri Oct 23, 2015 8:36 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
I also tried to find the APAR number, but I could not see it either. As others have pointed out, that does not prove that the fix is not present. Sometimes the headline summary does not tell the whole story.
I personally implemented the fix. It went into either 9.0.0.2 or 9.0.0.3. If you upgrade to 9.0.0.4 runtime you will see an improvement in DFDL deploy times. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 23, 2015 9:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Particularly since you can install the FP in a separate directory and run a separate broker on that FP for purposes of testing.
Other than cpu/mem impact, this doesn't interrupt any use of the other broker at the regular FP level. |
This is a very important point for v9 which I wish I'd remembered at time of posting....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 9:24 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Is there anything at the application level I should be checking?
Again, it's a DFDL with 1,200 elements. Some of field names are rather long? Like 50+ characters. Would shortening those help?
I'm newer to the DFDL modelling and followed the samples and labs to get what I needed, so I feel what I did is fine. Also, since I'm trying to deploy just the library, I definitely feel the route cause is the DFDL.
PS I tried all my other tricks as well :
deleted the bar and created a new bar
cleaned the project
deleted the integration server (EG) and recreated it.
If there is anything I can try to do from an application standpoint, I would appreciate some suggestions. Otherwise, I'm going to just need to deal with the long deployment times unless somehow I can make a case to upgrade.
 [/list][/code] |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Oct 23, 2015 9:59 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Your case is that they are 18 months (at least) out of date on fixes.
As stated before, the fix can and should be installed in a different directory. Then change the IIB service ID to use mqsiprofile from that directory. Then start the broker and test. If you have a problem because of the FP, then change the IIB to use the old mqsiprofile and recycle the broker and you are back to where you were. That is the point of fix packs not being on top of the main install.
You can open a PMR and they might be able to point to something specific and reference this thread in the PMR so they have a jump on the conversation. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri Oct 23, 2015 10:46 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
They are going to create me my own broker to work with.
Thanks for the help everyone. Have a great weekend. |
|
| Back to top |
|
|
|
|
