Menu
▾
▴
#151 Problems with getting service to work with JOPC bridge
Hello,
I am trying to get a third party java product to run
as a service using this wrapper. The product is
JOPCBridge from Net Module
(http://www.netmodule.com/en/products/netmodule_jopcbr
idge) and when I try to run it as a service it just
hangs. I have run the product using Java but when I
use the wrapper it fails on the first call to the
software.
The JOPCBridge allows java applications to access opc
servers. It provides a jar and dll file which must be
either in the classpath or the dll placed in the
java.library.path to get it to run from java.
Have you or any of your users come across this
behaviour or even used the two products.
Would appreciate any help.
Logged In: YES
user_id=228081
I have not used that particular application. How exactly is
it failing? Are you getting a stack trace? A hang? a crash?
The SAP native library is actually a pair of DLLs. The
first of which is a JNI native library. That DLL must be
located on the java.library.path. The second DLL is loaded
from the first as a standard DLL. On windows, this DLL is
searched for on the system PATH, not the library path.
If things are working when run in console mode, but not as a
service, then it is most likely a path problem. The wrapper
runs as the SYSTEM user by default, which will have an
entirely different environment from that of the user you are
normally logged in as.
An easy way to set this up is by doing the following. This
lets you place all of your DLLs in the same location, while
at the same time, keeping the configuration entirely in the
wrapper.conf file.
set.PATH=..%WRAPPER_FILE_SEPARATOR%bin%WRAPPER_PATH_SEPARATOR%%PATH%
set.LD_LIBRARY_PATH=..%WRAPPER_FILE_SEPARATOR%bin%WRAPPER_PATH_SEPARATOR%%LD_LIBRARY_PATH%
wrapper.java.library.path.1=bin
The LD_LIBARY_PATH is to make it work on UNIX based systems.
The DLLs are placed into the bin directory with the
wrapper.exe rather than in the lib directory to avoid
conflicts with files in the windows system directory.
Windows will always look in the user directory (bin) first,
then in the windows\system32, then the windows directory and
finally search along the PATH. If a user has an old DLL in
their windows dir then the application will have problems on
that one machine.
If you put it in the bit directory, you can actually omit
the set.PATH line. But it makes the configuration much
clearer as to what is going on.
There is a note about this here:
http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-n.html
Cheers,
Leif
Logged In: YES
user_id=1472892
Hello Leif,
I tried your suggestion of making the third party DLL's
available from the bin directory but it did not work. The
program is crashing see the attached crash report and the
corresponding wrapper log file.
Logged In: YES
user_id=1472892
Hello Leif,
Eventually got the system to work while running under the
wrapper. The problem would appear to be thread related.
I hope you can follow this:
The class that deals with the OPC is our OPCInterface
which implements runnable and executes within its own
thread. This interface is created by another class called
CollectorOperation and it executes within its own thread.
The OPCInterface class gets instantiated by the
constructor of the CollectorOperation class and it calls
the OPCInterface start method.
The start method creates all the OPC groups, adds all the
items to the appropriate groups and then creates the
listeners for each group via the third party software.
Then it creates the thread and sets it to run.
The overridden OPC call back readAsyncCallback method
writes to a queue which the OPCInterface class run method
blocks on. If the connect is called as above the Fatal
Error invalid interface pointers arose.
If the run method of the OPCInterface calls the connect
instead of the CollectorOperation then the system works
fine.
Running under java either method above works.
I have attached a diagram to help with the above.
Thread Diagram
Logged In: YES
user_id=228081
Sorry if I misunderstand. But from what you wrote it sounds
like this was a problem with your subclass of the OPC class
and not really Wrapper related. Were you able to reproduce
this problem running standalone without the Wrapper?
No problem, but just want to make sure that there is nothing
about the Wrapper that is causing your application to behave
differently.
Cheers,
Leif
Logged In: YES
user_id=1472892
Hello Leif,
This may be a bit confusing but the system is behaving
differently when run from the wrapper environment.
When run from Java either way of connecting to the OPC
server works, but under the wrapper the only way to get
the code to work is to call the connect method from the
OPCInterface thread as opposed to the CollectorOperation
thread.
I can not explain why it would be different behaviour but
at a guess it would appear that access to the DLL can only
be carried out from the thread that created them. Why this
works in Java and not the wrapper I can't explain.
Does threads get treated any differently under the wrapper?
Thanks.
Logged In: YES
user_id=1472892
Hello Leif,
My fix was short lived.
By changing the calls to Connected to the OPCInterface
thread I can no longer connect and disconnect. I get an
exception -
INFO | jvm 1 | 2006/03/23 12:32:18 |
Function 'CoCreateInstanceEx' failed !
INFO | jvm 1 | 2006/03/23 12:32:18 | Function
Failed : 800401F0h
When I revert back to the original method of calling it
from the CollectorOperation thread and run under Java I
can connect and disconnect several times without any
problems.
I am now back to square one i.e. The will not run under
the wrapper environment but it does run outside of the
wrapper.
Thanks!