Issue in JNI

WE are using WLS6.1
i am having issues in calliing JNI programs
from the servlet .The issues is that it gets called only sometime.WE have checked the LD library path , it seems to be ok .
Is there any service pack that needs to be put for JNI .

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.

Similar Messages

Very interesting and quizzical issue in JNI COding.

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);
     }

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.

Resource Contention Issue with JNI

Hello,
I'm trying to debug a webapp that contains a whole bunch of jsps that are relatively big. Under some unknown circumstances, the app stops responding and the threaddump shows a lot of threads trying to write a jsp response back to the user via jni:
[27/May/2008:09:40:47] WARNING (15372): CORE3283: stderr: "service-j2ee-116" prio=5 tid=0x013799e8 nid=0x163 runnable [0x2c7be000..0x2c7bf748]
[27/May/2008:09:40:47] WARNING (15372): CORE3283: stderr: at com.iplanet.ias.web.connector.nsapi.NSAPIConnector.jniWrite(Native Method)
[27/May/2008:09:40:47] WARNING (15372): CORE3283: stderr: at com.iplanet.ias.web.connector.nsapi.NSAPIConnector.write(NSAPIConnector.java:507)
Is this an indication of a problem either in the OS or HW?
Thanks,
RM

Rapapel wrote:
Thanks for the suggestion!
We are using an old version of the IPlanet Server (2004). We have the rqThrottle set to 512, which I think is too high.That does sound pretty high; I remember seeing that jniWrite stuff all the time under heavy loads. We recently migrated one server to Tomcat 6.0 64-bit, which has been more stable under heavy load (performance without the native APR connector sucked though). It took a little work to get the old iPlanet and the new Tomcat servers to share sessions properly, but well worth it. It also alleviated the memory pressure problem we were having with a 32-bit JVM (due to the overhead of the server, we were limited to around 900MB Java heap before problems with native heap started occurring). When we get time again, we'll migrate the rest of the servers.

JNI & thread problem

Folks,
I am using JNI to access WIA (Windows Image Acquisition) functionality under MS Windows XP. WIA consists of a bunch of COM interfaces. I have several native functions in a single dll, with a limited number of static variables stored in the dll between calls. This all works fine as long as long as the calls occur from the same java thread, but not if a new thread is created for some of the calls. I.e., this works:
final WIACtrl ctrler=new WIACtrl();
ctrler.initializeWIA();
ctrler.transferJPGNative("0001\\Root\\IMG_0087","c:\\test.jpg");
but this does not:
final WIACtrl ctrler=new WIACtrl();
ctrler.initializeWIA();
(new Thread() {
public void run() {
ctrler.transferJPGNative("0001\\Root\\IMG_0087","c:\\test.jpg");
}).start();
Here, initializeWIA() and transferJPGNative() are the native methods. What happens in the second case is that transferJPGNative fails in one of the COM methods (not the first COM method it calls). The COM method returns an HRESULT indicating an error (509) which I can't find using any of the usual MS error look-up mechanisms. (Admittedly I am not the world's greatest Windows programmer...)
Anyway, any suggestions would be much appreciated. I have found some issues regarding JNI and threads in this forum's archives, but none of them seem to apply to quite this situation.

As a guess this is just a windows threading problem.
And with COM you have to do things differently (I believe) if there is more than one thread. You might not even be allowed to do it with for that particular API.
It could also be that you are initializing things more than once. Or you need to initialize twice (two handles.)
At any rate you could always fix it by making the java code only allow calls for a single thread.

[svn:fx-trunk] 10065: Comment out code causing an RTE in SWFLoader.

Revision: 10065
Author:   [email protected]
Date:     2009-09-08 13:14:26 -0700 (Tue, 08 Sep 2009)
Log Message:
Comment out code causing an RTE in SWFLoader. Will fix as part of per-module styles feature development.
QE notes: None.
Doc notes: None.
Bugs: SDK-23081
Reviewer:
Tests run: checkintests
Is noteworthy for integration: no
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23081
Modified Paths:
    flex/sdk/trunk/frameworks/projects/framework/src/mx/controls/SWFLoader.as

Hello, first post here..
I maintain a java based lobby for an opensource RTS
engine called spring at http://taspring.clan-sy.com
You can find my lobbys source code at:
https://taspring.clan-sy.com/svn/spring/trunk/AFLobby/
Of note being the unitsync.dll/so library used to
handle mods and maps. Implementing this library in
pure java is not an option.
I've dealt with quite a few JNi errors dealing with
the linux users but we got through them all and it
all worked great.
I released a windows installer, and most users can
run it fine with no issues with JNI, but 2 users seem
to have problems, despite correctly installing
everything.Does the JNI code use perl?
This error message shows several hits on Google for perl related stuff.

Is there any known issue about mutex lock used in JNI on Solaris 10?

Dear Oracle,
I'm facing a strange behavior when running a JNI application that use the mutex lock. The application hanged after running for a while on one of our Solaris 10 machines. After investigating the stack trace of the application, it shows that one of all the application's threads that access the JNI hold the mutex lock forever, and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
The mutex function I used as show below:
mutex_lock(&mutex)
The application hanged at this line:
0xff2cc940 ___lwp_mutex_timedlock + 0x8
The Kernel version is SunOS 5.10 Generic_142900-14
Since this issue occurrs on only one Solaris 10 machine in our environment, we are wondering if there is any known issue regarding the mutex lock used in JNI on Solaris 10. We tried to search the Internet and the Java Bug database but found nothing related to this issue.
Best regards,
Krit K.

876587 wrote:
... and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
Different environments mean just that. So something could be causing it outside java.
Additionally if anything at all is different in the execution data, such as even a name having a different size, then it would change the execution path.
Which would cause a problem in the JNI code to manifest itself on only one box. Probably isn't a pointer bug but all sorts of odd behavior can result from that.

Issue while loading the library files(".so" or ".sl") using JNI

Hi,
We are loading the c library files using system.load during the init phase of servlet.
While loading the application for the first time everything goes smooth and application behaves as expected.
We are facing the below issue when we try restarting the application through admin console in case of WAS (web sphere) for any patch deployment in the application.
java.lang.UnsatisfiedLinkError: Native Library /users/test1/siva/jnilib.so already loaded in another classloader.
If we restart the complete WAS every thing works fine.
There is no specific System.unload function available in java to remove the loaded library in JVM.
Is there any alternate way to unload the library which is loaded in class loader to resolve this issue which can be called in the destroy phase of servlet?
Any help here is highly apreciated.
TIA,
Siva.

sivabalan wrote:
Hi,
We are loading the c library files using system.load during the init phase of servlet.
You mean a shared library, not C files (which would be source.)
However I am not sure that loading it in a servlet is a good idea. But that is a different issue.
Is there any alternate way to unload the library which is loaded in class loader to resolve this issue which can be called in the destroy phase of servlet?This is how it works on the Sun VM back to about 1.2. And as far as I know there is no other way for it to work on any other VM.
You have a class with native methods that relies on the shared library. The class and the shared library are loaded into a class loader. If the class loader is unloaded by the GC then the native library will be unloaded as well.
A class loader can be collected by the GC if if the classes loaded by it are no longer actively references. So ALL class instances can be collected.
If the above is true then by running System.gc() twice it will collect the classloader and thus the native library.
So in your situation it might work if your app server allows you do GC (full GC is better if that is an option). You could try unloading the app, then doing the GC option several times, then do a load. Try the GC option about 6 times and the reduce it down to see if 2 work.
If that doesn't work then there could be some programmatic solutions using the same idiom.

JNI memory/thread issue

Guys,
Here's the problem I'ce seen with JNI and using the JVM in C++.
I create AWT frames through a call to the constructor and access the window thro' call to the object.
before a call to DeleteGlobalRef, I call a Java method from C++ that calls dispose on the Frame.
I noticed that with time a lot of threads are not terminated and after a couple of creations and disposing of frames, the VM crashes.
Any thoughts....
Thanks.

You have a problem in your code.
If when you say "few" it means like 3-100, then the most likely explaination is you have buffer problem (over/under writing a buffer.) A problem like that does not cause problems until latter, sometimes much later, in the code.

JNI Multithreading/Callback Function Design Issues

Ok, I have been working on this for quite some time now and I simply can not figure it out. So any ideas are more than welcome. :)
I have Java code that uses a DLL that I created in C++. My C++ code links with a library made by a 3rd party (don't have access to the source or anything). The 3rd party's code creates a new thread and calls a callback function that I define in my C++ code. This callback is called continuously until I perform some other code to stop it. Now for the tricky part. In my callback function I need to pass some data back in Java. Here is where my design falls apart. Since the callback function is technically part of the 3rd party's thread, I have to call AttachCurrentThread() in the callback to get the JNIEnv pointer in order to ultimately call my desired Java method. The problem is that my Java method (or even the C++ callback function) are only invoked if I do a sleep() in my C++ code after I start the 3rd party code which creates the thread. If I do a Thread.sleep() in Java after I call the native function code, it just sleeps and the callbacks never get called. It appears as though the thread dies as soon as I return from my C++ code.
So now I am stuck. I have tried creating a thread in Java which simply calls the C++ code and the C++ code just loops waiting for an updated flag, however, this causes the 3rd party's thread creation code to fail (not quite sure why). However, even if their code worked, I'm not convinced this is even proper design. I apologize if this is simply a threading design principle as my multithreading programming techniques are a bit rusty and I've never done a multithreaded application this complex (this is a simplified version, but the idea is the same).
I welcome any suggestions or even documentation that may lead me in the right direction. Thanks in advance.

I have a similar issue.
from java I call a dll I wrote, which calls a third party scanner dll (cyber.dll). Everything works ok, except, when an event in the scanner occurs, it calls the call backin my dll, which calls the callback in java, which kills the vm with an access violation. If I execute the call back to java from a c method which I just called from java, it works, but if it gets called outside of the java execution of the native code, it fails.
I havent done anything with treads or syncronisation. Do I need to do this AttachCurrentThread stuff? If so, where do I get the _jvm handle as Im not starting the vm from c?

Interval Timing Issue On Solaris 10/Intel When The JNI Is Involved

We've observed an odd behavior bridging to interval timers over the JNI on Solaris 10/Intel, and I was wondering if anybody here has ever seen anything like this.
We have an interval timing facility that's implemented over a small set of platform-dependent native timing facilities. The *NIX "itimer" facility is used wherever it exists. On RedHat/Fedora we also implement a timer over the RTC device. On Windows we use a WaitableTimer.
On all platforms there's a Java class that bridges to an appropriate timing facility via the JNI, and to date this has worked great on all platforms except for Solaris 10 on Intel. By "worked great" I mean that the clock tics end up being almost exactly what we expect for a given configured Hz update rate. So... e.g. if we set up a timer for 50 Hz, then we actually get 50 Hz +/- some minor variation much less than 1 second.
On Solaris 10/Intel we set up a 50 Hz itimer in a plain-vanilla C app and we get ~50 Hz, but if we call the same C code from Java via the JNI we almost always end up with ~38Hz.
The amount of Java and native code involved is almost trivial, and the hardware is a smoking fast contemporary PC. We ran over the itimer facility on an old Sparc 5 box and it worked fine.
I've tried tweeking sundry esoteric -X and -XX JVM invocation options with no effect.
J2SDK 1.4.2-07 in all cases.
Thoughts?

I'd think you should be posting in the forum for the Solaris 10 os, not a Java forum. Maybe someone in the Java Native Methods forum would have the necessary Solaris 10 expertise, also.
If you do post elsewhere, either close this out with a final post or put a reference(s) to any other posts and say where you want replies posted, so replies aren't needlessly duplicated.

JNI Calls to Native Methods No Longer Work: Possible Versioning Issue ?

Hello, all. Just a quick question... is it possible that invoking a method in a JNI-compliant DLL from Java 6 will fail if the DLL's source was compiled against the JNI header files from Java 4 or 5 ? I have a DLL with methods that used to be called successfully (and now fail outright and don't even seem to be getting inside the native method), but it seems that the only thing that could have changed in the environment is the installed JRE. Even stranger, I don't get the hs_err* files anymore to indicate that the JVM crashed. Does anyone know why this might happen ? Thanks !

Cthulhu76 wrote:
Hello, all. Just a quick question... is it possible that invoking a method in a JNI-compliant DLL from Java 6 will fail if the DLL's source was compiled against the JNI header files from Java 4 or 5 ? Solely? No.
You could of course be doing something in the JNI code in terms of working with Java which no longer works. Just as it is at least possible that java code from one version might not work with another.
Correct error checking in the JNI code would at least correctly identify this problem however.
I have a DLL with methods that used to be called successfully (and now fail outright and don't even seem to be getting inside the native method), but it seems that the only thing that could have changed in the environment is the installed JRE.The only thing that you assume changed was the JRE.
You seem unsure whether the JNI is being called at all, so verifying that first would be a good idea.

Issue on solaris platform for JNI

hi all,
I am solaris platform.
I am passing string EFT�DEG from java to c++.
when I convert it in JNI code using GetStringUTFChars it changes to EFT�.DEG
I want to retain same character in c++ code ie. EFT�DEG
Can any one help me.

chetanpatil wrote:
when I convert it in JNI code using GetStringUTFChars it changes to EFT�.DEG
Explicitly explain how you are determining that it does not have the correct character.
I store it in file where that string store as EFT�.DEG.
Wrong.
That tells me what you are doing. That does NOT tell me how you are determining that it is wrong.
On windows it working but not on solaris platform.Which makes it really likely that you are confusing display with data.

JNI : Having issue with accessing C# dll

Hi Everyone,
Could you please tell me how to access C# dll using JNI.
My code looks like below:
public class JNISample {
     public native void Message();
static{
          System.load("D:/*******/JNISample/dll/SampleDLL.dll");
          System.out.println("library loaded");
     public static void main(String args[])
          System.out.println("JNI sample example");
          new JNISample().Message();
I created header file using command below
javah -jni -classpath d:\*****\JNISample\src JNISampleI am getting below error:
java.lang.UnsatisfiedLinkError: no D:/Applet/JNISample/dll/SampleDLL.dll in java.library.path
     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
     at java.lang.Runtime.loadLibrary0(Runtime.java:823)
     at java.lang.System.loadLibrary(System.java:1030)
     at JNISample.<clinit>(JNISample.java:16)
Exception in thread "main"
Could anyone please tell some suggestions?
Thanks,
Kavita
Edited by: java_pgrm on Dec 2, 2009 9:36 PM
Edited by: java_pgrm on Dec 2, 2009 9:38 PM

java_pgrm wrote:
I am really sorry to ask u such question.. What is .c file? Actually I am using c# dll. Java JNI requires a specific linkage which in general means that the JNI shared library must be written in C or C++.
What happens in that shared library is up to you. However note that fairly recent posts on this forum indicate that there are some complications about correctly using a JNI shared library with C#. Somewhere there is a thread that discusses it.
You might also consider just creating a separate executable with a comm interface (sockets, files, stdio) rather than using JNI. There are advantages to that including that it can't take down the VM (bad coding on your part in JNI can) and it is much easier to test.

Solaris - Windows JNI Issues

*** Setting the scene ***
I am trying to write a library called GuidGetPid which will have only 1 method to return the current pid.
The header file generated by javah only has the following declaration in it:
* Class:     GuidGenerator
* Method:    getPid
* Signature: ()I
JNIEXPORT jint JNICALL Java_GuidGenerator_getPid
(JNIEnv *, jclass);I am new to working with JNI, but I was succussful in implementing and running my program in Solaris.
The implementation in C is:
#include <unistd.h>
#include <jni.h>
#include "GuidGenerator.h"
JNIEXPORT jint JNICALL
Java_GuidGenerator_getPid(JNIEnv *env, jobject obj)
     return getpid();
}*** My problem ***
I am trying to implement this is WinXP now. In MS VC 6.0, I wrote the following cpp file.
#include <process.h>
#include <jni.h>
#include "GuidGenerator.h"
JNIEXPORT jint JNICALL
Java_GuidGenerator_getPid(JNIEnv *env, jobject obj)
     return getpid();
}Everything will compile, and java can find the library, but for some reason it cannot locate the method getPid. Specifically I get the error message
Exception in thread "main" java.lang.UnsatisfiedLinkError: getPid
        at com.ml.mlim.mlde.pls.GuidGenerator.getPid(Native Method)
        at com.ml.mlim.mlde.pls.GuidGenerator.nextID(GuidGenerator.java:49)
        at com.ml.mlim.mlde.pls.tester.main(tester.java:23)Does anyone have any suggestions as to how I can fix this?

Hmm... strangely (maybe not), it works for me. Here, I've posted everything I used, including the generated header file and the command line arguments I used.
****** Java source file ******
public class test
     public static native int getPid ();
     static
          System.loadLibrary ("test");
     public static void main (String [] args)
          System.out.println (getPid ());
}*******Generated header file********
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern "C" {
#endif
* Class:     test
* Method:    getPid
* Signature: ()I
JNIEXPORT jint JNICALL Java_test_getPid
(JNIEnv *, jclass);
#ifdef __cplusplus
#endif
#endif******** C source file ********
#include <jni.h>
#include <process.h>
#include "test.h"
JNIEXPORT jint JNICALL Java_test_getPid (JNIEnv *env, jclass cls)
     return (jint) getpid ();
}******* Command line arguments *******
cl -Ic:\j2sdk1.4.2\include -Ic:\j2sdk1.4.2\include\win32 test.c -LD -Fetest.dll
Hope any of that information helped.
If you still have problems, check if the dll is anywhere on your system (or rename it completely so that there will be no conflicts whatsoever).
Cheers.

Jni issues linux

I am trying to run a simple jni program fron this site "http://public.cabit.wpcarey.asu.edu/janjua/java/jni/ " on Red Hat Enterprise Linux AS release 4 and jdk 1.5.09 , AMD opteron. But when i run the command "gcc -I /usr/java/jdk1.5.0_09/include/ -I /usr/java/jdk1.5.0_09/include/linux/ -shared -o libhelloNative.so helloNative.c" i get the following error
/usr/bin/ld: /tmp/ccOjRonK.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccOjRonK.o: could not read symbols: Bad value
can anyone tell me a fix for this , I had no problem running the same program on Redhat Linux workstaion 3 with intel xeon processor
Thanks

I am trying to run a simple jni program fron this
site
"http://public.cabit.wpcarey.asu.edu/janjua/java/jni/
" on Red Hat Enterprise Linux AS release 4 and jdk
1.5.09 , AMD opteron. But when i run the command
"gcc -I /usr/java/jdk1.5.0_09/include/ -I
/usr/java/jdk1.5.0_09/include/linux/ -shared -o
libhelloNative.so helloNative.c" i get the
following error
/usr/bin/ld: /tmp/ccOjRonK.o: relocation R_X86_64_32
against `a local symbol' can not be used when making
a shared object; recompile with -fPIC
/tmp/ccOjRonK.o: could not read symbols: Bad value
can anyone tell me a fix for this , I had no problem
running the same program on Redhat Linux workstaion
3 with intel xeon processorWas the xeon processor 64 bit?
This isn't a JNI problem, its a 64 bit vs 32 bit problem.
Thanks

Issue in JNI

Similar Messages

Maybe you are looking for