Very interesting and quizzical issue in JNI COding.

Question

HI All,
i've been facing a really frustrating, interesting and mindwrenching issue in my native code. Here is a background.
1. I was given a thirdparty ACtiveX OCX file that needed to be called through JAva.
2. I wrote a C++ JNI wrapper to call the methods of the activex object.
3. I first initialize the object, set the relevant parameters (sent from java) and then call the method I need.
4. For every record, I need to perform step 3. NOw, I am ryuning batch loads. THE code works fine for 9500 records. BUt, once the record count reaches 9885, I get a pop-up error from the activeX OCX control. I've not coded that pop-up. It comes out of the blue.
I initially thought that it could be a memory issue, but even after doubling my VM Memory allocation, I get the error. Its not a data issue, because the reocrd that causes the issue, if I run the code just for that single record, it works fine.
Below is the implemetnation of the C++ code. LEt me know if I'm doign somethign wrong or if someone has seen something like this happen before. WHAt is baffling is that it works smoothly for less records. When the pop up appears, no exception is caught on the native side also.!!!
Does java set aside some memory specfic for native libs and that is exhausted after 9885?
I'm running on windows, so is it possible to trace the internal malloc and release within the dLL?
ANy thoughts and ideas will help. I've been struggling for about three days now. ALso, do you know of a good C++ forum that i could post this question?
#include "stdafx.h"
#include "jni.h"
#import "thirdparty.ocx" raw_native_types
JNIEXPORT jstring JNICALL Java_org_nik_integration_test_Exporter_saveAsImage
  (JNIEnv * env, jobject obj, jint height, jint width , jstring fileName, jstring encryptionKey, jshort encryptionAlgorithm, jstring encryptedImage, jshort imageType)
     const char* fName = NULL;
     const char* encryptionKeyc = NULL;
     const char* encImgc = NULL;
     ThirdPartyLib::_DTPPtr tpptr = 0;
     HRESULT hres = 0;
     try
          hres =  ::CoCreateInstance(__uuidof(ThirdPartyLib::TP),NULL,CLSCTX_ALL, __uuidof(ThirdPartyLib::_DTP), (void**)&tpptr);
          //Retrieve values sent from Java     
          fName = env->GetStringUTFChars(fileName,0);
          encryptionKeyc = env->GetStringUTFChars(encryptionKey,0);
          encImgc = env->GetStringUTFChars(encryptedImage,0);
                     tpptr->Key = _com_util::ConvertStringToBSTR(encryptionKeyc);
          tpptr->Algorithm = encryptionAlgorithm;
          tpptr->Img = _com_util::ConvertStringToBSTR(encImgc);
          tpptr->SaveUnencrypted(width, height,_com_util::ConvertStringToBSTR(fName) , 1);
     catch(_com_error &e)
          _bstr_t bstrSource(e.Source());
         _bstr_t bstrDescription(e.Description());
         printf( "Exception thrown for classes generated by #import" );
         printf( "\tCode = %08lx\n",      e.Error());
         printf( "\tCode meaning = %s\n", e.ErrorMessage());
         printf( "\tSource = %s\n",       (LPCTSTR) bstrSource);
         printf( "\tDescription = %s\n",  (LPCTSTR) bstrDescription);
         // Errors Collection may not always be populated.
         if( FAILED( hres ) )
            printf( "*** HRESULT ***" );
          return NULL;
     __finally
          tpptr->Release();
          tpptr = NULL;
          //Release memory - java specific
          env->ReleaseStringUTFChars(encryptionKey, encryptionKeyc);
          env->ReleaseStringUTFChars(ink, inkc);
          env->ReleaseStringUTFChars(fileName, fName);
     }

Answer 1

Well you have now demonstrated conclusively that it has nothing to do with JNI.
It is either a bug with that component and/or you are using it incorrectly. Solutions to either of those would come from the source of that component, which would be somewhere besides here.
If it was a bug then you might find a way around it by doing one of the following
1. Try variations of use (options, parameters, whatever.)
2. Determine if you can solve your problem by only processing 5000 entries at a time (where 5000 chosen just to be significantly lower than the limit you have already found.) If that works then you can solve the problem by using a restartable executable that wraps the component.