Search Results

Search found 5 results on 1 pages for 'workmanagers'.

Page 1/1 | 1 

  • NameNotFoundException when calling a EJB in Weblogic 10.3

    - by XpiritO
    First of all, I'd like to underline that I've already read other posts in StackOverflow (example) with similar questions, but unfortunately I didn't manage to solve this problem with the answers I saw on those posts. I have no intention to repost a question that has already been answered, so if that's the case, I apologize and I'd be thankful to whom points out where the solution is posted. Here is my question: I'm trying to deploy an EJB in WebLogic 10.3.2. The purpose is to use a specific WorkManager to execute work produced in the scope of this component. With this in mind, I've set up a WorkManager (named ResponseTimeReqClass-0) on my WebLogic configuration, using the web-based interface (Environment Work Managers New). Here is a screenshot: Here is my session bean definition and descriptors: OrquestratorRemote.java package orquestrator; import javax.ejb.Remote; @Remote public interface OrquestratorRemote { public void initOrquestrator(); } OrquestratorBean.java package orquestrator; import javax.ejb.Stateless; import com.siemens.ecustoms.orchestration.eCustomsOrchestrator; @Stateless(name = "OrquestratorBean", mappedName = "OrquestratorBean") public class OrquestratorBean implements OrquestratorRemote { public void initOrquestrator(){ eCustomsOrchestrator orquestrator = new eCustomsOrchestrator(); orquestrator.run(); } } META-INF\ejb-jar.xml <?xml version='1.0' encoding='UTF-8'?> <ejb-jar xmlns='http://java.sun.com/xml/ns/javaee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' metadata-complete='true'> <enterprise-beans> <session> <ejb-name>OrquestradorEJB</ejb-name> <mapped-name>OrquestratorBean</mapped-name> <business-remote>orquestrator.OrquestratorRemote</business-remote> <ejb-class>orquestrator.OrquestratorBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor></assembly-descriptor> </ejb-jar> META-INF\weblogic-ejb-jar.xml (I've placed work manager configuration in this file, as I've seen on a tutorial on the internet) <weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>OrquestratorBean</ejb-name> <jndi-name>OrquestratorBean</jndi-name> <dispatch-policy>ResponseTimeReqClass-0</dispatch-policy> </weblogic-enterprise-bean> </weblogic-ejb-jar> I've compiled this into a JAR and deployed it on WebLogic, as a library shared by administrative server and all cluster nodes on my solution (it's in "Active" state). As I've seen in several tutorials and examples, I'm using this code on my application, in order to call the bean: InitialContext ic = null; try { Hashtable<String,String> env = new Hashtable<String,String>(); env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); env.put(Context.PROVIDER_URL, "t3://localhost:7001"); ic = new InitialContext(env); } catch(Exception e) { System.out.println("\n\t Didn't get InitialContext: "+e); } // try { Object obj = ic.lookup("OrquestratorBean"); OrquestratorRemote remote =(OrquestratorRemote)obj; System.out.println("\n\n\t++ Remote => "+ remote.getClass()); System.out.println("\n\n\t++ initOrquestrator()"); remote.initOrquestrator(); } catch(Exception e) { System.out.println("\n\n\t WorkManager Exception => "+ e); e.printStackTrace(); } Unfortunately, this don't work. It throws an exception on runtime, as follows: WorkManager Exception = javax.naming.NameNotFoundException: Unable to resolve 'OrquestratorBean'. Resolved '' [Root exception is javax.naming.NameNotFoundException: Unable to resolve 'OrquestratorBean'. Resolved '']; remaining name 'OrquestratorBean' After seeing this, I've even tried changing this line Object obj = ic.lookup("OrquestratorBean"); to this: Object obj = ic.lookup("OrquestratorBean#orquestrator.OrquestratorBean"); but the result was the same runtime exception. Can anyone please help me detecting what am I doing wrong here? I'm having a bad time debugging this, as I don't know how to check out what may be causing this issue... Thanks in advance for your patience and help.

    Read the article

  • Set up Work Manager Shutdown Trigger in WebLogic Server 10.3.4 Using WLST

    - by adejuanc
    WebLogic Server's Work Managers provide a way to control work and allocated threads. You can set different scheduling guidelines for different applications, depending on your requirements. There is a default self-tuning Work Manager, but you might want to set up a custom work manager in some circumstances: for example, when you want the server to prioritize one application over another when a response time goal is required, or when a minimum thread constraint is needed to avoid deadlock. The Work Manager Shutdown Trigger is a tool to help with stuck threads in which will do the following: Shut down the Work Manager. Move the application to Admin State (not active). Change the Server instance health state to failed. Example of a Shutdown Trigger set on the config.xml for your domain: <work-manager>   <name>stuckthread_workmanager</name>   <work-manager-shutdown-trigger>     <max-stuck-thread-time>30</max-stuck-thread-time>     <stuck-thread-count>2</stuck-thread-count>   </work-manager-shutdown-trigger> </work-manager> Understand that any misconfiguration on the Work Manager can lead to poor performance on the server. Any changes must be done and tested before going to production. How can one create a WorkManagerShutdownTrigger for WLS 10.3.4 using WLST? You should be able to create a WorkManagerShutdownTrigger using WLST by following these steps: edit() startEdit() cd('/SelfTuning/mydomain/WorkManagers') create('myWM','WorkManager') cd('myWM/WorkManagerShutdownTrigger') create('myWMst','WorkManagerShutdownTrigger') cd('myWMst') ls()

    Read the article

  • Tuning Default WorkManager - Advantages and Disadvantages

    - by Murali Veligeti
    Before discussing on Tuning Default WorkManager, lets have a brief introduction on What is Default WorkManger Before Weblogic Server 9.0 release, we had the concept of Execute Queues. WebLogic Server (before WLS 9.0), processing was performed in multiple execute queues. Different classes of work were executed in different queues, based on priority and ordering requirements, and to avoid deadlocks. In addition to the default execute queue, weblogic.kernel.default, there were pre-configured queues dedicated to internal administrative traffic, such as weblogic.admin.HTTP and weblogic.admin.RMI.Users could control thread usage by altering the number of threads in the default queue, or configure custom execute queues to ensure that particular applications had access to a fixed number of execute threads, regardless of overall system load. From WLS 9.0 release onwards WebLogic Server uses is a single thread pool (single thread pool which is called Default WorkManager), in which all types of work are executed. WebLogic Server prioritizes work based on rules you define, and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool.The common thread pool changes its size automatically to maximize throughput. The queue monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues. The Default WorkManager is used to handle thread management and perform self-tuning.This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors. In many situations, the default Work Manager may be sufficient for most application requirements. WebLogic Server’s thread-handling algorithms assign each application its own fair share by default. Applications are given equal priority for threads and are prevented from monopolizing them. The default work-manager, as its name tells, is the work-manager defined by default.Thus, all applications deployed on WLS will use it. But sometimes, when your application is already in production, it's obvious you can't take your EAR / WAR, update the deployment descriptor(s) and redeploy it.The default work-manager belongs to a thread-pool, as initial thread-pool comes with only five threads, that's not much. If your application has to face a large number of hits, you may want to start with more than that.Well, that's quite easy. You have  two option to do so.1) Modify the config.xmlJust add the following line(s) in your server definition : <server> <name>AdminServer</name> <self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min> <self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max> [...] </server> 2) Adding some JVM parameters Add the following system property in setDomainEnv.sh/setDomainEnv.cmd or startWebLogic.sh/startWebLogic.cmd : -Dweblogic.threadpool.MinPoolSize=100 -Dweblogic.threadpool.MaxPoolSize=100 Reboot WLS and see the option has been taken into account . Disadvantage: So far its fine. But here there is an disadvantage in tuning Default WorkManager. Internally Weblogic Server has many work managers configured for different types of work.  if we run out of threads in the self-tuning pool(because of system property -Dweblogic.threadpool.MaxPoolSize) due to being undersized, then important work that WLS might need to do could be starved.  So, while limiting the self-tuning would limit the default WorkManager and internally it also limits all other internal WorkManagers which WLS uses.So the best alternative is to override the default WorkManager that means creating a WorkManager for the Application and assign the WorkManager for the application instead of tuning the Default WorkManager.

    Read the article

  • Record and Play your WebLogic Console Tasks Like a DVR

    - by james.bayer
    Automation using WebLogic Scripting Tool Today on the Oracle internal mailing list for WebLogic Server questions someone asked how to automate the configuration of the thread model for WebLogic Server and they were having trouble with the jython scripting syntax.  I’ve previously written about this feature called Work Managers and the associated constraints.  However, I did not show how to automate the process of configuring this without the console using WebLogic Scripting Tool – the jython scripting automation environment abbreviated as WLST.  I’ve written some very basic introductions to WLST before and there is also an Oracle By Example on the subject, but this is a bit more advanced.  Fear not because there is a really easy-to-use feature of the WLS console that lets you “Record” user actions just like a DVR.  Using these recordings of the web-based console, you can easily create a script even if you are unfamiliar with the WLST syntax and API.  I’m a big fan of both DVR’s and automation as can be evidenced with this old Halloween picture taken during simpler times.  Obviously the Cast Away and The Big Labowski references show some age.  I was a big Tivo fan-boy back in the day and I still think it’s the best DVR. I strongly believe that WebLogic Scripting Tool (WLST) is an absolutely essential tool for automating administration tasks in anything beyond a development environment.  Even in development environments you can make a case that it makes sense to start the automation for environments downstream.  I promise you that once you start using it for any tasks that you do even semi-regularly, you won’t go back to clicking through the console.  It’s simply so much more efficient and less error-prone to run a script. Let’s say you need to create a Work Manager and MaxThreadsConstraint – the easy way to do it is configure it in the WLS console first while capturing the commands with a recording.  See the images for the simple steps – click to enlarge. Record Console Configurations to a File Review the Recordings and Make Slight Modifications In order to make the recorded .py file directly callable as a stand-alone script I added calls to the connect() and edit() functions at the beginning and calls to disconnect() and exit() at the end – otherwise the main section of the script was provided by the console recording.  Below is the resulting file I saved as d:/temp/wm.py connect('weblogic','welcome1', 't3://localhost:7001') edit() startEdit()   cd('/SelfTuning/wl_server') cmo.createMaxThreadsConstraint('MaxThreadsConstraint-0')   cd('/SelfTuning/wl_server/MaxThreadsConstraints/MaxThreadsConstraint-0') set('Targets',jarray.array([ObjectName('com.bea:Name=examplesServer,Type=Server')], ObjectName)) cmo.setCount(5) cmo.unSet('ConnectionPoolName')   cd('/SelfTuning/wl_server') cmo.createWorkManager('WorkManager-0') cd('/SelfTuning/wl_server/WorkManagers/WorkManager-0') set('Targets',jarray.array([ObjectName('com.bea:Name=examplesServer,Type=Server')], ObjectName))   cmo.setMaxThreadsConstraint(getMBean('/SelfTuning/wl_server/MaxThreadsConstraints/MaxThreadsConstraint-0')) cmo.setIgnoreStuckThreads(false)   activate() disconnect() exit() Run the Script If you want to test it be sure to delete the Work Manager and MaxThreadConstraint that you had previously created in the console.  Do something like the following - set up the environment and tell WLST to execute the script which happens in the first 2 lines, the rest doesn’t require any user input: D:\Oracle\wls11g\wlserver_10.3\samples\domains\wl_server\bin>setDomainEnv.cmd D:\Oracle\wls11g\wlserver_10.3\samples\domains\wl_server>java weblogic.WLST d:\temp\wm.py   Initializing WebLogic Scripting Tool (WLST) ...   Welcome to WebLogic Server Administration Scripting Shell   Type help() for help on available commands   Connecting to t3://localhost:7001 with userid weblogic ... Successfully connected to Admin Server 'examplesServer' that belongs to domain 'wl_server'.   Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead.   Location changed to edit tree. This is a writable tree with DomainMBean as the root. To make changes you will need to start an edit session via startEdit().   For more help, use help(edit)   Starting an edit session ... Started edit session, please be sure to save and activate your changes once you are done. Activating all your changes, this may take a while ... The edit lock associated with this edit session is released once the activation is completed. Activation completed Disconnected from weblogic server: examplesServer     Exiting WebLogic Scripting Tool.   Now if you go back and look in the console the changes have been made and we now have a compete script.  Of course there is a full MBean reference and you can learn the nuances of jython and WLST, but why not the WLS console do most of the work for you!  Happy scripting.

    Read the article

  • Weblogic Bea 10.0 M1 and WorkManager

    - by ma-ver-ick
    Hi there! I have to execute long running threads in a WebLogic Bea 10.0 M1 server environment. I tried to use WorkManagers for this. Using an own WorkManager allows me to specify my own thread timeout (MaxThreadStuckTime) instead of adjusting the timeout for the whole business application. My setup is as follows: weblogic-ejb-jar.xml: <?xml version="1.0" encoding="UTF-8"?> <weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>TestBean</ejb-name> <resource-description> <res-ref-name>myWorkManager</res-ref-name> <jndi-name>wm/myWorkManager</jndi-name> </resource-description> </weblogic-enterprise-bean> </weblogic-ejb-jar> weblogic-application.xml: <?xml version="1.0" encoding="UTF-8"?> <weblogic xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic.xsd"> <work-manager> <name>myWorkManager</name> <ignore-stuck-threads>1</ignore-stuck-threads> </work-manager> </weblogic> and the Bean: import javax.annotation.Resource; import javax.ejb.Stateful; import weblogic.work.WorkManager; @Stateful(mappedName = "TestBean") public class TestBean implements TestBeanRemote { @Resource(name = "myWorkManager") private WorkManager myWorkManager; public void test() { myWorkManager.schedule(new Runnable() { public void run() { while (true) { System.out.println("test: +++++++++++++++++++++++++"); try { Thread.sleep(45000); } catch (InterruptedException e) { e.printStackTrace(); } } } }); } } When I try to deploy this things, the server gives me the following exceptions: [EJB:011026]The EJB container failed while creating the java:/comp/env namespace for this EJB deployment. weblogic.deployment.EnvironmentException: [EJB:010176]The resource-env-ref 'myWorkManager' declared in the ejb-jar.xml descriptor has no JNDI name mapped to it. The resource-ref must be mapped to a JNDI name using the resource-description element of the weblogic-ejb-jar.xml descriptor. I try to figure out how to access / use WorkMangers for days now, and still get this or that as an exception. Very frustrating! Thanks in advance!

    Read the article

1