Execution flow doesn't wait for return values

Question

I have created JNI wrappers for existing dlls. However I'm getting weird behavior. My Java function calls a c function which communicates with an old mainframe. If I retrieve one row at a time its fine but if I do a loop the virtual machine crashes. Sometimes, if I add an empty loop for (30000 iterations) then its fine. Its like java is already trying to retrieve the next row while the first row is still being printed on my screen. I've tried adding synchronized in case the dlls where multi-threaded but it has not made a difference. Is there any way to control the execution flow so that it can't go to the next line until the values are truly returned from the c dll.
thanks
MA

Answer 1

There are many function being called on the native side. Since I didn't want to modify the native side
(because the old dlls are used by another application), I added my own dll as an intermediary between the old c dlls and the java side.
To fix the problem I am having, I've heard of another project where the native side would write the returned values to a file and only once the file is written can the Java side continue. Is this the only way to control the execution flow?
Right now I have about 5 empty loops which run to 100000 and things work most of the time. But I would prefer to find a way to say wait until the values are returned correctly.
Essentially, what I'm doing is
for (int i=1;i<10; i++){
   test.init(Integer.toString(i),Integer.toString(i),"english desc"+  Integer.toString(i),"french desc"+ Integer.toString(i));
   test.execute(test.ActionAdd);
}This is supposed to add one row with four fields. I'm just putting junk for the test. If I call the two main lines
test.init(Integer.toString(i),Integer.toString(i),"english desc"+  Integer.toString(i),"french desc"+ Integer.toString(i));
test.execute(test.ActionAdd);just once it works fine but if I loop them then it crashes after a few loops. If I put a loop as shown below then it works fine. This is part of the code when I'm adding. Is it being looped 10 times from the code above.
jsession.scanTable(table,errorlist);
            rtc = table.getRecordCount(errorlist);
            if (rtc > 0)
            publish(rtc+" records found.");
                for(int i = 1; i <= rtc; ++i)
                    for (int j = 0; j < ElementName.size();j++)
                        publish((String)ElementName.get(j)+ ": " + table.getFieldByName((String)ElementName.get(j),i,errorlist));
                        for (int k = 0; k<100000;k++);
            else
                publish("No records found.");
            }In the code, when the rows are added, I print them out just to make sure they were added correctly. This is where I got the idea that the Java code was not in synch with the native side because it would crash while writting out a line but it didn't happen every time at the same place.
This is the function getFieldByName
public String getFieldByName (String p_FieldName, int p_LineNum, ErrorList p_Errors)
          String retval = "";
          int ret;
          try
               p_FieldName = prepareFieldName(p_FieldName);
               retval = new String();
               ret    = 0;
               if (this.ptrTableView == NOT_SET)
                    p_Errors.addMessage(p_Errors.SEV_SYSTEM_ERROR(), "Table View Pointer not set");
                    throw (new Exception());
               // allocating string buffer for value returned
               StringBuffer m_FieldValue = new StringBuffer();
               // determining length of value
               int m_length[] = {0};
               ret = gti.GetFieldLen(this.ptrTableView, p_FieldName, m_length, eb.getErrorBlockPtr());
               if (m_length[0] == 0) m_length[0] = 100;
               m_FieldValue = new StringBuffer(m_length[0]);
               // get line field          
               ret = gti.GetLineField(this.ptrTableView, p_FieldName, p_LineNum, m_FieldValue, eb.getErrorBlockPtr());           
               if (ret != 0)
                      p_Errors.addMessage(p_Errors.SEV_ERROR(), "Error retrieving field value ("+p_FieldName+")");
               else
                      retval = m_FieldValue.toString();
          catch (Throwable t)
               p_Errors.addMessage(p_Errors.SEV_ERROR(), "Error retrieving field value ("+p_FieldName+")");
          return retval;
    }The main functions are
GetFieldLen
GetLineField
They go to the native side through my dll which wraps the old dlls.
Here are is one of the main functions in my dll. I also have the source for the functions they are calling but they are calling other functions which are calling other functions. There is a lot of code . Yes, they use arrays.
JNIEXPORT jint JNICALL Java_advantagewrapperspk_GtiNative_GtiGetLineField
  (JNIEnv *env, jclass cls, jint p_tableViewPtr, jstring VIEWFIELDNAME, jint VIEWFIELDNUM, jobject VIEWFIELDVALUE, jint iErrBlockPtr)
       //printf("\n\nGtiGetLineField in C:\n");
       jint iResult = 0;
       char *temp1 = (*env)->GetStringUTFChars(env,VIEWFIELDNAME,0);
       char *temp2 = (*env)->GetStringUTFChars(env,VIEWFIELDVALUE,0);
     iResult = GtiGetLineField(p_tableViewPtr,temp1,VIEWFIELDNUM,temp2,iErrBlockPtr);
       //printf("VIEWFIELDNUM %d ",VIEWFIELDNUM);
       //printf("\ntemp1 %s ",temp1);
       //printf("\ntemp2 %s ",temp2);
     (*env)->ReleaseStringUTFChars(env,VIEWFIELDNAME,temp1);
     if (temp2 == 0)      return iResult;
    if (temp2 != NULL)
            cls = (*env)->GetObjectClass(env,VIEWFIELDVALUE);
            jmethodID mid = (*env)->GetMethodID (env,cls,"append","(Ljava/lang/String;)Ljava/lang/StringBuffer;");
             if (mid == 0) return iResult;
             jstring sfinal = (*env)->NewStringUTF (env, temp2);
            (*env)->CallObjectMethod(env,VIEWFIELDVALUE,mid,sfinal);
          if (VIEWFIELDVALUE != NULL) (*env)->ReleaseStringUTFChars(env,VIEWFIELDVALUE,temp2);
     //(*env)->ReleaseStringUTFChars(env,VIEWFIELDVALUE,temp2);
     return iResult;
  }This calls
* Function Name : GtiGetLineField()
* Description   : Retrieves the value of a line field in a table view
* Parameters    : pTableViewPtr pTableView--the table view from which to
*                                           retrieve the value of a line
*                                           field
*                 VIEWFIELDNAME szFieldName--the name of the line field
*                                            whose value is returned
*                 VIEWLINENUM iLineNum--number of line from which to retrieve
*                                       field value.  Lines are numbered
*                                       beginning with 1.
*                 VIEWFIELDVALUE szFieldValue--returns the value of the
*                                              line field
*                 ErrBlockPtr sourceeb--error context info from calling
*                                       function
* Return values : int--returns RCT_RETURNOK, RCT_WARNCORECONNECT, or
*                      RCT_FAILCORECONNECT
* Modifications : REH - 05/25/93
int GtiGetLineField ( TableViewPtr pTableView,
                      VIEWFIELDNAME szFieldName,
                      VIEWLINENUM iLineNum,
                      VIEWFIELDVALUE szFieldValue,
                      ErrBlockPtr sourceeb )
   int iRc ;      /* return code */
   ELOG_INIT( sourceeb,
              "GtiGetLineField",
              "retrieving the value of a line field in a table view" ) ;
   /* in Gti, we start numbering lines from 1, because that is the way a user
      sees them on the screen.  In Ldm, following C conventions, we start
      numbering lines at 0.  So in LdmSetField, we subtract 1 from iLineNum */
   iRc = LdmGetField( pTableView->pTran,
                      szFieldName,
                      szFieldValue,
                      iLineNum - 1,
                      0,                  /* map occurrence = 1 */
                      ELOG_ERRBLOCK ) ;
   /* in case Ldm returned a warning, indicate so to the calling function */
   iRc = ( iRc == LDM_RETURNOK ) ? RCT_RETURNOK : RCT_WARNCORECONNECT ;
   return( iRc ) ;
   /* if exception was raised, it was due to COREConnect */
   ELOG_END( RCT_FAILCORECONNECT ) ;
}which calls
/****************************** API Header *********************************\
* API Name: LdmGetField
* This function copies the string value of a specified FIELDNAME into a
* buffer specified by FIELDVALUE.  The string is NULL terminated.
* The first OCCUR determines which occurrence of the field in the map.
* The second OCCUR determines which occurence of the map in the transaction
* area.  Remember that occurrences are numbered like C arrays: a transaction
* with ten occurrences of a field will have fields numbered zero through
* nine.
* It is assumed that FIELDVALUE has enough space to accommodate the field's
* value.
int LdmGetField( HTRAN       htran,
                 FIELDNAME   fieldname,
                 FIELDVALUE  fieldvalue,
                 FIELDOCCUR  fieldoccur,
                 MAPOCCUR    mapoccur,
                 ErrBlockPtr seb )
   ELOG_INIT ( seb, "LdmGetField", "getting transaction field value" ) ;
   if ( htran->Occurrence <= mapoccur ) {
      ElogFail1( LDM_FAILOCCNOTFOUND, htran->TranName ) ;
   }  /* END if. */
   /* Since 'blank' values for field or map occurrences are zero, there
      is no need to set a default. */
   LdmsGetField( htran->Map->CCMap,
                 htran->TranData,
                 fieldname,
                 fieldvalue,
                 fieldoccur,
                 mapoccur,
                 ELOG_ERRBLOCK ) ;
   return( LDM_RETURNOK ) ;
   ELOG_END ( ELOG_ERRBLOCK->Rc ) ;
}  /* END LdmGetField. */which calls
/****************************** API Header *********************************\
* API Name: LdmsGetField
* Put the value of FIELDNAME into FIELDVALUE.  The field must be an element
* of the specified map.  The new value will be set in the specified data
* buffer.  The occurrences refer to the occurrence of the field in the map
* and the occurrence of the map in the data buffer.
int LdmsGetField ( CCMapPtr    rcmap,
                   char        *dataarea,
                   FIELDNAME   fieldname,
                   FIELDVALUE  fieldvalue,
                   FIELDOCCUR  fieldoccur,
                   MAPOCCUR    mapoccur,
                   ErrBlockPtr seb )
   ElementPtr element ;
   char       *fieldoffset ;
   ELOG_INIT ( seb, "LdmsGetField", "getting a field of a map" ) ;
   /* Search the transaction definition area (map) for matching
      FIELDNAME. If found, copy FIELDVALUE to defined offset in
      transaction buffer. */
   element = LdmsFindField( rcmap, fieldname, fieldoccur, &localeb ) ;
   /* Copy the value from the transaction data area into FIELDVALUE. */
   fieldoffset = dataarea +
                 ( ( rcmap->BufferLength * mapoccur ) + element->Offset ) ;
   strncpy( fieldvalue, fieldoffset, element->Length ) ;
   fieldvalue[ element->Length ] = '\0' ;
   return( LDM_RETURNOK ) ;
   ELOG_END ( ELOG_ERRBLOCK->Rc ) ;
}  /* END LdmsGetField. */and on it goes
I gather from your question about arrays that they might be the source of the problem. Could it be that the pointer to the array is returned while the array is not completed? Any information would help. Thanks.