We have recently discovered a problem in our update installer and I can’t seem to find a proper workaround. In our update installer we have a special action that performs DB updates. Running the update code outside of IA takes about 40 seconds. However, when I add the same code the a IA custom action and run it inside the installer the execution takes minimum 3 times as much. I cannot seem to find an explanation to this. I spent significant amount of time analyzing the problem and here are my findings: - The problem is specific to SunOS and Linux platforms. Running the installer on windows performs perfectly. - The performance difference is unacceptable. At least 3 times (300%) slower using some simple code but it can be even more under certain conditions. - I played a lot with the VM arguments (JRE version 1.5 and 1.6, heap size, client / server switch etc) none of these seem to have any effect. - Surprisingly, simply hooking up a debugger to the process seems to eliminate the bottleneck and the code performs just like in standalone mode. I don’t understand why. - When I profiled the execution using JProfiler it showed that some 50% of the processor time is spent in some system level X11 toolkit thread (see below). - I tried to disable some of the AWT event handling by pushing my own, no-op event handler to the framework, tried to suspend some AWT threads, increase the local thread’s priority etc. but none of these helped. - When running the installer in silent mode with or without display set is still running slow. - Running the same code on a custom panel instead of an action makes no difference in the execution time. I have attached a simple sample Java code, jar file and install project that shows the problem. If I run the Java code on RE4 it takes about 11 sec. to complete (make sure you have a large (1GB) heap as it only adds elements to a hashmap) while running it inside the custom action it takes about 44 seconds to complete. Anybody have any idea if there is anything we can do with this on our side? Any help it greatly appreciated. Zoltan ... View more

Hi Everyone, I am trying to upgrade our Flex API to the latest verion from version 10.8.5.0 and I am having problems. It keeps complaining that our vendor keys are incorrect and does not build the utilities. If I simply try to use the jar file from the latest version of the Java API it also complains about the keys which is weird because we have been using these vendor keys in production environment for almost 3 years no (that's when we switched to TRL keys). Here is the e-mail I sent to support: Dear Support, We are currently using FlexLM API v10.8.5.0. Our framework and developer kits are using both the Java and C++ API on both Windows and UNIX platforms. So far we needed license checkout capability on 32-bit libraries only. Due to the Java API our licenses are TRL enabled. I have recently started to do a pilot task for Windows based 64-bit developer kit libraries. Unfortunately I ran into issues with building and using the FlexLM libraries. 1. First I tried to build the current v10.8.5.0 version of the 64-bit windows toolkit. When the make process gets to the point of generating the lm_new.c using the lmnewgen utility it compains about our vendor key being incorrect: C:\Development\flexlm\v10\x64_n6>lmnewgen.exe v8.1+ FLEXlm, using TRL lc_init failed: Invalid key data supplied. FLEXnet Licensing error:-44,49 For further information, refer to the FLEXnet Licensing End User Guide, available at "www.macrovision.com". I tried to slightly change the makefile and force the build process to use the lm_new.c file generated as part of the i86 build (lm_new.obj and lm_new_md.obj). Our test application builds and links fine using these binaries but when running it and trying to create a Flex job the first time I get a return code of -1 and none of the FlexLM functionality is available. 2. I tried the same process using the new v11.5 and also the v11.6 C++ API. I get the exact same behavior but this time I cannot even build and use the win32 obj and library file. C:\Program Files\FLEXlm\v11.6\i86_n3>lmnewgen.exe v8.1+ FLEXnet, using TRL lc_init failed: Invalid key data supplied. FLEXnet Licensing error:-44,49 For further information, refer to the FLEXnet Licensing documentation, available at "www.acresso.com". C:\Program Files\FLEXlm\v11.6\i86_n3>cd ../.. C:\Program Files\FLEXlm>cd v10.8.5.0\i86_n3 C:\Program Files\FLEXlm\v10.8.5.0\i86_n3>lmnewgen v8.1+ FLEXlm, using TRL I have double and triple checked that I am using the exact same lm_code.h file and the vendor name has been properly updated in the makefile each time I tried. My questions are the following: 1. Is there something wrong with our vendor keys? I am not sure why I can use it on win32 without any problems but when I try to build it in 64-bit mode or try to use a higher version of FlexLM API with the same keys it comes out as incorrect. 2. Is it possible that our keys are locked somehow to this specific platform and FlexLM version? Here is the full output when trying to build the v11.6 binaries: C:\Program Files\FLEXlm\v11.6\i86_n3>nmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. lmrand1 -i ..\machind\lsvendor.c cl /c /nologo /c /I..\machind /I. /MT -I../h lmcode.c lmcode.c LINK /nologo /NODEFAULTLIB /OPT:NOREF /subsystem:CONSOLE lmnewgen.obj l mcode.obj .\activation\lib\libnoact.lib lmgr.lib libcrvs.lib libsb.lib oldnames .lib kernel32.lib user32.lib netapi32.lib advapi32.lib gdi32.lib comdlg32.lib comctl32.lib wsock32.lib libcmt.lib /out:lmnewgen.exe if exist lm_new.c del lm_new.c lmnewgen.exe osp -o lm_new.c v8.1+ FLEXnet, using TRL lc_init failed: Invalid key data supplied. FLEXnet Licensing error:-44,49 For further information, refer to the FLEXnet Licensing documentation, available at "www.acresso.com". NMAKE : fatal error U1077: '.\lmnewgen.exe' : return code '0x1' Stop. C:\Program Files\FLEXlm\v11.6\i86_n3> And here is the output from the v10.8.5.0: C:\Program Files\FLEXlm\v10.8.5.0\i86_n3>nmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. rc /l 0x409 /r /folmwin.res ..\machind\lmwin.rc lmrand1 -i ..\machind\lsvendor.c cl /c /nologo /c /I..\machind /I. /MT -I../h lmcode.c lmcode.c LINK /nologo /NODEFAULTLIB /OPT:NOREF /subsystem:CONSOLE lmnewgen.obj l mcode.obj lmgr.lib libcrvs.lib libsb.lib oldnames.lib kernel32.lib user32.lib n etapi32.lib advapi32.lib gdi32.lib comdlg32.lib comctl32.lib wsock32.lib libc mt.lib /out:lmnewgen.exe if exist lm_new.c del lm_new.c lmnewgen.exe osp -o lm_new.c v8.1+ FLEXlm, using TRL cl /nologo /c /I..\machind /I. /MT /Folm_new.obj lm_new.c lm_new.c cl /nologo /c /I..\machind /I. /MT /O1 ..\machind\lmsimple.c lmsimple.c LINK /nologo /NODEFAULTLIB /OPT:NOREF /out:lmsimple.exe lmsimple.obj lm _new.obj lmgr.lib libsb.lib libcrvs.lib oldnames.lib kernel32.lib user32.lib net api32.lib advapi32.lib gdi32.lib comdlg32.lib comctl32.lib wsock32.lib libcmt .lib if exist lmsimple.obj del lmsimple.obj cl /nologo /c /I..\machind /I. /MT /O1 ..\machind\lmflex.c lmflex.c … and more. I hope I provided enough details about the problems we are having. Please let me know if you need any additional information. Any input is appreciated. It almost looks like our vendor keys have been incorrectly issues or generated by Macrovision. ... View more