IBM webMethods Hybrid Integration

IBM webMethods Hybrid Integration

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  IS java service thread safe

    Posted Fri February 11, 2005 08:36 PM

    I’m debugging a java service that someone else wrote. The symptoms lead me to beleive there is a threading problem. It is possible to put a synchronize clause on the IS server java service? The routines we are calling (supplied by SAG) JADABAS don’t appear to be thread safe. And of course getting the vendor to change their interface could take a long time.

    Thanks in advance for any help!! Sincerely, …Kevin


    #Integration-Server-and-ESB
    #webMethods
    #Flow-and-Java-services


  • 2.  RE: IS java service thread safe

    Posted Fri February 11, 2005 11:00 PM

    It’s difficult to respond without more details but…

    Are you clear that when invoked, your Java service is running as a static method, and the implications thereof?

    So the question is… do you really need synchronization within the Java service ( with it’s potential performance problems ) or do you just need to create an independent object instance on each Java service invoke with independent data?

    Regards


    #Flow-and-Java-services
    #Integration-Server-and-ESB
    #webMethods


  • 3.  RE: IS java service thread safe

    Posted Sat February 12, 2005 07:48 PM

    I’m not positive which I need. From what I’m seeing the vendor supplied jars (SAG) they appear to have static variables that should’t change during execution. Running threads one at a time against it, it apears to work just fine (test java application), but when I run it from within webMethods, it producing symptoms like threading problems. The vendor has given us a way to trace their execution. And in the trace we’ll see things like; open, select, open, close select close. So it appears if the multiple threads are causing problems. If I run it in a single threaded test application, I get the exepcted sequence: open, select, close, open, select, close, etc. Leaving the connection open isn’t a solution, their software will croak after x amount of inactivity. I’d be willing to take the performance hit on the synhronization. Or at least be willing to try it (if possible) to see what happens.

    Any suggestion on how to do that? Thanks in advance!


    #webMethods
    #Flow-and-Java-services
    #Integration-Server-and-ESB


  • 4.  RE: IS java service thread safe

    Posted Sat February 12, 2005 07:54 PM

    Have you enabled garbage collection on the IS, this sometimes works incase the number of inactive threads are not getting removed.

    Also, does this java service have any SQL calls or any file read, open, close occurring.


    #webMethods
    #Integration-Server-and-ESB
    #Flow-and-Java-services


  • 5.  RE: IS java service thread safe

    Posted Sat February 12, 2005 09:50 PM

    Garbage collection is “enabled” in IS all the time because IS runs in a JVM that uses garbage collection (1.3.1 or 1.4.2 for IS 6.x).

    If you post a suggestion to schedule a forced System.gc() I will have to ban you from WM Users for life.

    You can add the synchronized key word to methods defined in the “common” source code area and use those to wrap your calls to the third-party methods.

    Mark


    #Flow-and-Java-services
    #Integration-Server-and-ESB
    #webMethods


  • 6.  RE: IS java service thread safe

    Posted Sat February 12, 2005 10:04 PM

    You said you created a single-threaded test application.
    What happens if you create two of them, and make one sleep before doing the select. While it is sleeping, start the second test program without the sleep. If the second program completes, and after, when the first program wakes up, it completes its open/select/close sequence without error, you have proven that the jadabas jar is thread safe (at least in this case).

    If this is the case, you only need to create a new object instance in your Java service to perform the interaction with jadabas. So after getting your data out of the pipeline, your Java service would do something like [ new MyClass(parm1,parm2).talkToAdabas() ]. Needless to say, in MyClass, the variables that store your connection info from Jadabas should not be static!

    I’ve seen the Integration Server get locked up in handling synchronization of it’s own threading. Try not to add to this risk with your own code.


    #webMethods
    #Integration-Server-and-ESB
    #Flow-and-Java-services