WebSphere Application Server & Liberty

WebSphere Application Server & Liberty

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
Expand all | Collapse all

ManagedThreadFactory and ManagedThreadExecutor in z/OS Connect EE and OSGi Liberty Feature

  • 1.  ManagedThreadFactory and ManagedThreadExecutor in z/OS Connect EE and OSGi Liberty Feature

    Posted Mon May 15, 2023 03:04 PM
    Edited by Sharbel Nasra Mon May 15, 2023 03:07 PM

    Hi,
    I developed z/OS Connect EE intereceptor for API provider and API Requester exit points,its OSGi Liberty feature is .ESA file  as descibed here
    Creating a monitoring interceptor 

    Ibm remove preview
    Creating a monitoring interceptor
    You create a monitoring interceptor by implementing the Interceptor interface and optionally, one or more of its subinterfaces.
    View this on Ibm >

     
     and I am creating my own thread to capture the exit point data and and send the data over TCP/IP listener, I want this thread for collection to be managed 
    by the Liberty Container, so Liberty will be responsible to submit the thread depending of what workload in the Liberty.
    So I am trying to implement that whithin the OSGi Liberty Feature following these two reference here :https://www.ibm.com/docs/en/was-liberty/zos?topic=manually-configuring-managed-executors

    In server.xml we want to define our JNDI names :
                                                                                                                           
     <managedExecutorService jndiName="concurrent/MjeZconnInterceptorEx" contextServiceRef="contextSvc1"/>                             
     <managedThreadFactory jndiName="concurrent/MjeZconnInterceptorTF" createDaemonThreads="true" contextServiceRef="contextSvc1"/>    
                                                                                                                                       
     <contextService id="contextSvc1">                                                                                                 
          <classloaderContext/>                                                                                                        
          <jeeMetadataContext/>                                                                                                        
     </contextService>         

    In our code we tried to implement ManagedExecutorService & ManagedThreadFactory. We want to do Lookup() for JNDI namespace when we create and submit the worker thread (MjeWorker Thread) previously defined in server.XML.
    From IBM doc there is way to define these resources in web.xml. unfortunately since our interceptor is not webApp project we getting javax.naming.NameNotFoundException: javax.naming.NameNotFoundException: java:comp/env/concurrent/MjeZconnInterceptorEx 
    Link: https://www.ibm.com/docs/en/was-liberty/zos?topic=manually-configuring-managed-executors
    Our question is, is there a way to make it work in OSGi Application (maybe to add some declarations in MANIFEST.MF file).

    This is what we trying to do in Java code:

      public void postInvoke(...)
    {
       *
       *
       *
         try {
                     ManagedExecutorService executor = 
                              (ManagedExecutorService) new InitialContext().lookup(
                              "java:comp/env/concurrent/MjeZconnInterceptorEx");
                             
                      ManagedThreadFactory threadFactory =(ManagedThreadFactory) new InitialContext().lookup(
                              "java:comp/env/concurrent/MjeZconnInterceptorTF");
                         
                      
                      Thread mjeWorkerThread = threadFactory.newThread(mjeWorker);
                      Boolean deamonFlag=new Boolean(mjeWorkerThread.isDaemon());
                      GlobalBean.mjeWTO(String.format("MJEZC0SNI Thread Name = %s , Deamon= %s , Thread priority = %d ", mjeWorkerThread.getName(),deamonFlag.toString(),mjeWorkerThread.getPriority()), 'I');
                      executor.submit(mjeWorkerThread);
                            
                } catch (Exception e) {
                      // TODO Auto-generated catch block
                      e.printStackTrace();
                }
    *
    *
    *

    }
     regards,
    Sharbel



    ------------------------------
    Sharbel Nasra
    ------------------------------



  • 2.  RE: ManagedThreadFactory and ManagedThreadExecutor in z/OS Connect EE and OSGi Liberty Feature

    Posted Tue May 16, 2023 09:54 AM
    Edited by Kristen Park Tue May 16, 2023 03:36 PM

    Usage of ManagedExecutorService and ManagedThreadFactory from OSGi (non-Java/Jakarta EE application) falls outside of Java/Jakarta EE programming model.  However, Liberty does allow you to perform direct lookups of many resource types (via the jndiName that is configured in server.xml), including these.  Ensure you have the jndi-1.0 Liberty feature enabled and try:

    ManagedExecutorService executor = 
                              (ManagedExecutorService) new InitialContext().lookup(
                              "osgi:service/jakarta.enterprise.concurrent.ManagedExecutorService/(osgi.jndi.service.name=concurrent/MjeZconnInterceptorEx)");

    It also needs to be pointed out that your approach of using ManagedThreadFactory to create a Thread and submitting that Thread as a Runnable to ManagedExecutorService is inefficient and does not do what you are probably expecting it to do.  The ManagedExecutorService.submit(Runnable) API accepts a Runnable instance and arranges for a thread from the ManagedExecutorService upon which to apply context per the ManagedExecutorService configuration and invoke the .run() method to perform the requested operation.  So your Thread.run() runs on a ManagedExecutorService thread, not on the ManagedThreadFactory Thread instance that you requested with a particular daemon status, priority, or context.  You configured both with the same context propagation, so that part wouldn't matter here, except that you are incurring the overhead of capturing context an extra time for the ManagedThreadFactory.  You should leave out the ManagedThreadFactory entirely and submit the Runnable mjeWorker directly to the ManagedExecutorService.



    ------------------------------
    Nathan Rauh
    ------------------------------