SOA 11g cluster: Unable to create Queue producer due to JMSException .

Problem: 
- SOA server with integration involving JMS queue throws following errors in the .out log.

Important Error Messages:
JMSMessageProducer_produce:[default destination = jms/LZBSOMInternalMessageQueue]:ERRJMS_ERR_CR_QUEUE_PROD.
ERRJMS_ERR_CR_QUEUE_PROD.
Unable to create Queue producer due to JMSException.
..
Caused by: weblogic.jms.common.JMSException: [JMSExceptions:045103]While trying to find a topic or a queue we could not find the specific JMSServer requested. The linked exception may contain more information about the reason for failure



Relevant log excerpt from soa server .out file:
<Oct 12, 2018 7:32:37 PM EDT> <Error> <oracle.soa.adapter> <BEA-000000> <JMS Adapter  SOMSalesOrder:EnqueueStartAckMessage [ Produce_Message_ptt::Produce_Message(body) ]  JMSMessageProducer_produce:[default destination = jms/LZBSOMInternalMessageQueue]:ERRJMS_ERR_CR_QUEUE_PROD.
ERRJMS_ERR_CR_QUEUE_PROD.
Unable to create Queue producer due to JMSException.
Please examine the log file to determine the problem.
>
<Oct 12, 2018 7:32:37 PM EDT> <Error> <oracle.soa.adapter> <BEA-000000> <JMS Adapter  SOMSalesOrder:EnqueueStartAckMessage [ Produce_Message_ptt::Produce_Message(body) ]  JmsProducer_execute:[default destination = jms/LZBSOMInternalMessageQueue]: A resource exception occured while producing message>
<Oct 12, 2018 7:32:37 PM EDT> <Error> <oracle.soa.adapter> <BEA-000000> <JMS Adapter  SOMSalesOrder:EnqueueStartAckMessage [ Produce_Message_ptt::Produce_Message(body) ]
BINDING.JCA-12137
ERRJMS_ERR_CR_QUEUE_PROD.
ERRJMS_ERR_CR_QUEUE_PROD.
Unable to create Queue producer due to JMSException.
Please examine the log file to determine the problem.
....
....
....
Caused by: weblogic.jms.common.JMSException: [JMSExceptions:045103]While trying to find a topic or a queue we could not find the specific JMSServer requested. The linked exception may contain more information about the reason for failure.
        at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
        at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncNoTran(DispatcherAdapter.java:61)
        at weblogic.jms.client.JMSSession.createDestination(JMSSession.java:3192)
        at weblogic.jms.client.JMSSession.createQueue(JMSSession.java:2577)
        at weblogic.jms.client.WLSessionImpl.createQueue(WLSessionImpl.java:938)
        at oracle.tip.adapter.jms.JMS.JMSDestination.getQueue(JMSDestination.java:70)
        at oracle.tip.adapter.jms.JMS.JMSConnection.createProducer(JMSConnection.java:696)
        ... 88 more
Caused by: weblogic.jms.common.JMSException: [JMSExceptions:045103]While trying to find a topic or a queue we could not find the specific JMSServer requested. The linked exception may contain more information about the reason for failure.
        at weblogic.jms.dispatcher.Request.handleThrowable(Request.java:87)
        at weblogic.jms.dispatcher.Request.getResult(Request.java:52)
        at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:1124)
        at weblogic.messaging.dispatcher.DispatcherImpl.syncRequest(DispatcherImpl.java:185)
        at weblogic.messaging.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:288)
        at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncNoTran(DispatcherAdapter.java:59)
        ... 93 more
Caused by: weblogic.jms.common.JMSException: [JMSExceptions:045103]While trying to find a topic or a queue we could not find the specific JMSServer requested. The linked exception may contain more information about the reason for failure.
        at weblogic.jms.frontend.FEManager.destinationCreate(FEManager.java:294)
        at weblogic.jms.frontend.FEManager.invoke(FEManager.java:572)
        at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:961)
        ... 96 more

Root Cause Analyses:

On further investigation it was found that the subdeployment to which the jms queue is assigned, was targetted on only node 2 of the SOA cluster, and the node was shutdown for maintenance. 

Fortunately, we had a planned maintenance on node 2, else we'd have never identified that the jms configuration are not targetted evenly on the cluster.

Resolution:
Target the subdeployment evenly, i.e. on the relevant JMS servers from both nodes.

GUI tests on Windows RDP session stops working after minimizing or disconnecting

Many automation tests require the GUI based application or scripts to keep running on a windows session.
In a standard IT industry scenario, we use RDP session (with mstsc) to connect to a windows server.

However, the challenge comes when we need to leave these applications unattended. In most scenarios, once you minimize the RDP session window, all the GUI operation get stuck, and the application or script is unable to proceed normally.

The situation worsens when we have even longer running tests/scripts, as its not possible for end user to continuously monitor the RDP session.

The trick to deal with both these situations are mentioned below:

1. Minimizing the RDP window halts the GUI test/scripts:

To prevent the minimized RDP sessino from stopping your work, make the following changes

a. Launch registry editor using regedit
b. Navigate to the below two following registries & create an entry as shown below:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client

HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client

Create an entry of type DWORD, with name RemoteDesktop_SuppressWhenMinimized and set its value to 2(decimal value).


2. Disconnecting the RDP session totally stop the execution of GUI activities:

Sometimes is impractical to keep the session continuously monitored. In my case, I had setup a script that needs to runs every 10 minutes, 24x7, and it didn't need any user inputs.

To achieve successful execution of GUI based tests or scripts, with "unconnected*" [*notice that I avoided the term disconnected], use the below commands for closing the RDP session

a. Create a bat file with below contents:

for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do ( %windir%\System32\tscon.exe %%s /dest:console )

a. Run the above created file with admin privilege:
- Please note, the script won't work unless you run it as administrator.

With this, your session will show disconnected, however, the user will in reality will be still logged in, and GUI tasks will go on as expected.

Credits:
Thanks to some of the blogs on web:

https://superuser.com/questions/1288469/remote-windows-server-virtual-machine-always-keep-desktop-open-simulate-rdp-se
https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/in-minimized-window.html