Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer) with Oracle® JDeveloper

The problem

Using JDeveloper 12.1.3, I had created a dummy BPMN Process with just a User Task bound to a human task. For this task I had also auto-generated an input form. Deploying the task form went fine, but when trying to deploy the BPMN process I got the following error:

[08:30:27 AM] Deployment cancelled.

[08:30:27 AM] Taskflow deployment failed to deploy to server. Remote deployment failed

[08:30:27 AM] Deployment cancelled.

[08:30:27 AM] ----  Deployment incomplete  ----.

[08:30:27 AM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)

The cause

After trying various things, I discovered the problem was my proxy settings in Oracle® JDeveloper.

The solution

Tools -> Preferences -> Web Browser and Proxy -> Proxy Settings, and then I set it to No Proxy. 

Now I could deploy the process without any errors. 

I assume it would also have worked if I had set it to Manual Proxy Settings, and then added my hostname to the exception list.

The art of creating efficient algorithms

How often do we think outside the box to create a creative and efficient algorithm when we develop software? I bet answer is "probably not often enough". I have not been coding in Python for close to two years. In fact I have not been coding much for the past two years in any language apart from a few Java utilities and the odd shell scripts to help me get things done in a predicable and automated manner. Hence this is not a post about how to create good algorithms, but rather some reflections on code performance during my re-entry to Python programming. So please forgive me for any false assumptions and poor code quality.

While reading a book on Python 3 recently, I came across an interesting anecdote about the German mathematician Carl Friedrich Gauss, who at the age of 8 was given a homework assignment to sum up all the numbers between 1 and 100. To his teacher’s astonishment Carl Friedrich answered 5050 a few seconds later, and it was the teacher had to go home and check if the answer was correct.

Instead of adding every number between 1 and 100, the young Carl Friedrich quickly realized that there were 50 pairs of unequal numbers that would sum up to 100:
99 + 1
98 + 2
And so on, all the way down to 51 + 49
And since he had not included the number 50 yet, the answer was (50 pairs * 100) + 50 = 5050

So the youngster had by himself discovered a pretty efficient algorithm for summing up integers. Not bad for an 8 year old! According to Wikipedia this story is contested, but nevertheless it is a very good example of a creative solution for optimizing an algorithm.

Naturally I needed to test the same logic on a computer, so I wrote a small Python script to check the human way of thinking (the count()method) and the young Carl Friedrich' way of thinking (the f_count() method):

import time

class FunnyMath(object):

    def __init__(self,num=0):
        self.num = num
   
    def count(self,num=0):
        start = time.time()
        self.num = num;
        for i in range(1,num):
            self.num += i
        end = time.time()
        print("Traditional approach took {} seconds to get the result: {}".format(round((end-start),2),int(self.num)))
    
    def f_count(self,num=0):
        start = time.time()
        self.num = num**2/2.0 + num/2.0
        end = time.time()
        print("Creative approach took {} seconds to get the result: {}".format(round((end-start),2),int(self.num)))
    
def main():
    fm = FunnyMath()
    num = 100000000
    fm.f_count(num)
    fm.count(num)
   
if __name__ == "__main__":
    main()

How long it takes to run will of course depend on your hardware resources. I tested this script on two different laptops.

On the "fast" laptop I got the following output:
Creative approach took 0.0 seconds to get the result: 5000000050000000
Traditional approach took 14.88 seconds to get the result: 5000000050000000

On the "slow" laptop I got the following output:
Creative approach took 0.0 seconds to get the result: 5000000050000000
Traditional approach took 27.76 seconds to get the result: 5000000050000000

So it is an interesting example that shows that some algorithms can and should be optimized. Not only did f_count() perform better. It also had fewer lines of code.

 But with a rewrite I could also optimize the slow count() method:

import time

class FunnyMath(object):

    def __init__(self,num=0):
        assert type(num) is int, "num was not an integer {}".format(num)
        self.num = num
   
    def count(self):
        num = self.num
        for i in range(1,num):
            num += i
        return int(num)
        
    def f_count(self):
        return int(self.num**2/2.0 + self.num/2.0)
    
def main():
    fm = FunnyMath(num = 100000000)
    start = time.time() 
    num = fm.f_count()
    end = time.time()
    print("Creative approach took {} seconds to get the result: {}".format(round((end-start),2),num))
    
    start = time.time()
    num = fm.count()
    end = time.time()
    print("Traditional approach took {} seconds to get the result: {}".format(round((end-start),2),num))
    
if __name__ == "__main__":
    main()

Then I ran it on the "fast" laptop and got the following output:
Creative approach took 0.0 seconds to get the result: 5000000050000000
Traditional approach took 5.98 seconds to get the result: 5000000050000000

A full rewrite was not really necessary, but I wanted a cleaner and more compact code for my class. The observant reader might have spotted the real problem with the first definition of the count() method:

def count(self,num=0):
        start = time.time()
        self.num = num;
        for i in range(1,num):
            self.num += i
        end = time.time()
        print("Traditional approach took {} seconds to get the result: {}".format(round((end-start),2),int(self.num)))
 
For each iteration in the loop I was updating the class variable num instead of just using a local variable called num, so the same performance gain for the count() method could have been achieved with a small rewrite:

def count(self,num=0):
        start = time.time()
        num = num;
        for i in range(1,num):
            num += i
        end = time.time()
        print("Traditional approach took {} seconds to get the result: {}".format(round((end-start),2),int(num)))

When I ran that on the "fast" laptop I got the the following output:
Traditional approach took 5.92 seconds to get the result: 5000000050000000

The reason for this performance gain is explained in the Python wiki.

Still, the count() method would always be slower than the f_count() method.

weblogic.store.PersistentStoreFatalException: [Store:280019]There was an error while writing to a storage

The problem

We discovered that an Oracle® WebLogic managed server was in status FAILED on a development environment. The apparent reason for this was the following error:

weblogic.store.PersistentStoreFatalException: [Store:280019]There was an error while writing to a storage

The cause

The can be multiple reasons or the above error, but the logical guess was that our /data mount point had run out of disk space, because that mount point was where our domain configuration (and persistent stores) were saved. That theory turned out to be wrong. The /data mount point was only 12% utilized on a 100GB partition, so there was plenty of available disk.

Then I tried to create an empty file on the mount point:

# touch /data/dummy

# touch: cannot touch `/data/dummy': Read-only file system

When checking the /var/log/messages file, I found the reason for that:

May 11 07:37:45 <hostname> kernel: JBD2: I/O error detected when updating journal superblock for dm-25-8.

May 11 07:37:45 <hostname> kernel: EXT4-fs error (device dm-25): ext4_journal_start_sb: Detected aborted journal

May 11 07:37:45 <hostname> kernel: EXT4-fs (dm-25): Remounting filesystem read-only

Comparing the commands cat /etc/fstab and ls -l /dev/mapper/ | grep dm-25 also confirmed that device dm-25 was indeed the source for the /data mount point.

The solution

After shutting down everything as cleanly as I could, I checked if there were still processes trying to use the /data mount point:

lsof | grep "/data"

It turned out that there was a few processes I was unable to shutdown cleanly, so I had to kill those. 

Then I unmounted the /data mount point:

umount /data

Finally I fixed the issue by running fsck and mounting the partition again. 

Caution: Running fsck on a partition can in worst case scenario be destructive, so make sure you have a valid backup!

fsck /data

mount /data

Now I could start up Oracle® WebLogic Server without any issues.

RDA-10913: Unknown profile "FM12c_SoaMin" when running Remote Diagnostic Agent on Oracle® SOA Suite 12.1.3

The problem

You are trying to collect information about the Oracle® SOA Suite 12.1.3 using the Remote Diagnostic Agent (RDA), but it fails with a RDA-10913: Unknown profile "FM12c_SoaMin" error, like shown below:

source $DOMAIN_HOME/bin/setDomainEnv.sh

cd $SOA_ORACLE_HOME

cd ../oracle_common/rda

./rda.sh -s soa_issue -p FM12c_SoaMin

RDA-00013: Error reported by the command "setup":

 RDA-00014: Request error "Setup":

  RDA-10913: Unknown profile "FM12c_SoaMin"

The cause

There is something wrong with the RDA supplied with  Oracle® SOA Suite 12.1.3, and this is how I discovered that:

The command ./rda.sh -V told me I was running RDA 8.02, which looked fine.

By reading the full output from ./rda.sh -V I could also see that the required modules where installed, according to Oracle Support Doc ID 391983.1.

Using ./rda.sh -h told me which options RDA is accepting, And in particular I noted the -L flag:

-L     List the available modules, profiles, and conversion groups

./rda.sh -L | grep Soa

  FM11g_Soa                        Oracle SOA Suite 11g problems

  FM11g_SoaMin                     Oracle SOA Suite 11g problems (minimum)

As you can see, the RDA shipped with Oracle® SOA Suite 12.1.3 was only supporting Oracle® SOA Suite 11g diagnostics.

The solution

1. Downloaded the latest version of the RDA tool for Oracle® Fusion Middleware. At the time of writing this, the patch number was 22783073.
2. Used opatch apply to install the patch I just downloaded.
3. Verified which SOA profiles were now available by running:
   ./rda.sh -L | grep Soa
   OFM_SoaMax                       OFM SOA Suite problems (11g/12c+) : full
   OFM_SoaMin                       OFM SOA Suite problems (11g/12c+) : minimum
    
4. Ran the RDA with the new module for Oracle® SOA Suite 11g and 12c:
   ./rda.sh -s soa_issue -p OFM_SoaMin

Oracle® WebLogic managed server reaches ADMIN state during startup due to name collision

The problem

When starting a Oracle® WebLogic managed server it halts when reaching the ADMIN state. 

Looking at the managed server's out file I saw the following error:

<Mar 15, 2016 8:45:40 AM UTC> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application "MyDataSource".

weblogic.application.ModuleException: weblogic.common.ResourceException: Failed to bind remote object (ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 null)/289        [weblogic.jdbc.common.internal.RemoteDataSource]) to replica aware stub at MY_DS(ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 [6058417782957188722S:my-server:soa_domain:soa_server1/288])/288        [weblogic.jdbc.common.internal.RemoteDataSource])

        at weblogic.jdbc.module.JDBCModule.activate(JDBCModule.java:411)

        at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:114)

        at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:195)

        at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:190)

        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)

        Truncated. see log file for complete stacktrace

Caused By: weblogic.common.ResourceException: Failed to bind remote object (ClusterableRemoteRef(6058417782957188722S:my-server:soa_domain:soa_server1 null)/289   [weblogic.jdbc.common.internal.RemoteDataSource]) to replica aware stub at MY_DS(ClusterableRemoteRef(6058417782957188722S:my-server:

The cause

The error above says I have a problem starting the MyDataSource data source due to a name collision. Logging into the WebLogic console, and looking at my data sources, I realized I had two data sources with the same JNDI location. The reason was that I had prepared a new data source long time ago, and forgotten all about it. During the startup of the managed server, my new data source had started up, but the old one could of course not start since it had the same JNDI  location.

The solution

1. Removed the old and obsolete data source with the conflicting JNDI location.
2. Checked the managed server's out file for other errors, and there were none. 
3. Resumed startup of the managed server so the server state changed from ADMIN to RUNNING. 

Oracle® SOA Suite 12.1.3 startup fails with CoherenceException due to ensureWKAAddresses

The problem

After a fresh install of Oracle® SOA Suite 12.1.3 with BPM and BAM enabled, both the SOA server and the BAM server failed to startup due to the following exception:

<Mar 9, 2016 9:49:34 AM UTC> <Error> <weblogic-coherence-integration> <BEA-000012> <Server bam_server1 is configured with localhost as the Unicast Listen Address which is an error in Coherence Production mode. A generated Coherence WKA list will not operate correctly across multiple machines.>

Mar 09, 2016 9:49:36 AM oracle.dms.servlet.DMSServletFilter setEagerlySetContextValues

INFO: The setting that controls the eager fetching of some types of execution context data has been set to true.

<Mar 9, 2016 9:49:37 AM UTC> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:

There are 1 nested errors:

weblogic.cacheprovider.coherence.CoherenceException:

    at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)

    at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)

    at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)

    at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)

    at weblogic.cacheprovider.CacheProviderServerService.initialize(CacheProviderServerService.java:71)

    at weblogic.cacheprovider.CacheProviderServerService.start(CacheProviderServerService.java:65)

    at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)

    at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:497)

    at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)

    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)

    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)

    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)

    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)

    at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)

    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)

    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)

    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)

    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)

    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)

    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)

    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)

    at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)

>

<Mar 9, 2016 9:49:37 AM UTC> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED.>

<Mar 9, 2016 9:49:37 AM UTC> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down.>

<Mar 9, 2016 9:49:37 AM UTC> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN.>

The cause

As stated in the exception, the issue is that the servers are listening on localhost instead of the actual hostname while the Oracle® WebLogic Server is running in Production mode.

The solution

There are multiple solutions to this one, but the two most obvious ones are to either run Oracle® WebLogic Server is running in Development mode, or to listen to the actual hostname instead of localhost. I would not recommend the former. Not unless it is a single user development system.

Run the hostname command to find the actual hostname. The hostname command works on both Linux, Unix and Windows.

Edit the managed servers through the  Oracle® WebLogic Server console, and set the value returned from the hostname command as the Listen Address,

Could not initialize class sun.awt.X11GraphicsEnvironment for frevvo module in Oracle® BPM Suite 12.2.1

The problem

BPM Composer in Oracle® BPM Suite 12.2.1 fails when open enterprise maps, and the SOA server's out file says:

<Mar 1, 2016 7:31:43 AM UTC> <Error> <HTTP> <BEA-101017> <[ServletContext@881844748[app:frevvo module:/frevvo path:null spec-version:3.1]] Root cause of ServletException.

java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment

    at java.lang.Class.forName0(Native Method)

    at java.lang.Class.forName(Class.java:264)

    at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)

    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)

    at sun.awt.X11FontManager.isHeadless(X11FontManager.java:511)

    Truncated. see log file for complete stacktrace

>

The cause

The JVM was not running headless, and it did not have a DISPLAY variable set to point to a X server.

The solution

Added -Djava.awt.headless=true to the soa server, and restarted it.