Coherence 12.1.3 Videos

We have posted 4 new videos on the Oracle Coherence YouTube Channel explaining and demonstrating some of the new features in the recent Coherence 12.1.3 release.

Worth a look to get you up to speed on some of the new features!

Posted in News | Tagged , | Leave a comment

Fusion Middleware 12.1.3 released

Originally posted on RedStack:

Fusion Middleware 12.1.3 is now available for download from OTN.  This release includes WebLogic Server, Coherence, ADF, SOA, OSB and BPM.

Here is the documentation site.

The download page for SOA/BPM is here.

View original

Posted in Uncategorized | Leave a comment

Coherence 12.1.3 Released

As part of the wider Oracle Fusion Middleware 12c (12.1.3.0.0) release, Coherence 12.1.3 was released overnight.

The new version of Coherence has a number of cool new features, some of which I’ve outlined below:

  • New memcached protocol support allowing a Coherence cluster to be used as a replacement for memcached servers. This allows memcached clients using the binary protocol to switch to using a Coherence cluster for storage. See here for details.
  • Coherence JVisualVM Plug-in, originally part of the Coherence Incubator, is now released as part of the Coherence distribution.  See the JMX documentation for more information.
  • Support has been added for JCache (JSR-107) implementation within Coherence. See the Oracle JCache documentation.
  • You can now submit asyncrhnonous entry processors which is very cool. See the com.tangosol.util.processor.AsynchronousProcessor API in the documentation.
  • The NameService has been enhanced to run on all cluster members. This means you can connect to any member to look up a proxy service.
  • In Managed Coherence Servers in WebLogic Server, you can now designate a node as a management proxy, which allows easier connection to Coherence MBean servers.

There has also been various index rebuild performance enhancements on failover as well as more forward and backward compatibility for Coherence*Extend clients and servers.

Please see here for the full list of new features and changes.

Posted in News | Tagged , , | Leave a comment

Getting Started with Coherence*Web in WebLogic Server 12.1.2

Introduction

Coherence*Web is a great feature which allows you to store your HTTP sessions in a Coherence Cluster.  Doing this allows your to de-couple the HTTP sessions from your JVM’s that are running your web apps, (which can free up JVM memory) and take advantage of the RASP (Reliability, Availability, Scalability and Performance) capabilities of Coherence for storage.

With this separation you can also more easily scale and manage and your HTTP session tier as well as utilise the wide array of session management options that Coherence*Web provides.

What I’d like to show you here is how to configure Coherence*Web in WebLogic Server 12.1.2 and deploy a basic web application that utilises this.

For more detailed information on Coherence*Web and the options available, see http://docs.oracle.com/middleware/1212/coherence/COHCW/start.htm#sthref11.

Setup

For this example, I’m assuming you already have installed WebLogic Server 12.1.2 and created a domain with node manager running.

If you are not familiar with how to do this, then you can use one of my posts here as a starting point or see the product documentation here.

We are going to create two WebLogic Server Clusters and a Coherence cluster into which we shall place both WLS clusters. This will ensure that the manages servers in both WLS clusters are associated with a common set of Coherence caching services

  • StorageTier – 2 Coherence managed servers storage1 and storage2. This tier will hold the HTTP session data.
  • ClientTier – 2 regular application managed servers client1 and client2 – We will deploy our application to this tier.

Typically you would have multiple servers in each tier and have a load balancer in front, but for this example, we will just 2 which is the minimus to demonstrate session fail-over.

Once you have your AdminServer and node manager up and running, login to the console to carry out the following steps.

1. Create a Coherence Cluster

  • Navigate to Domain Structure then Environment and click on Coherence Clusters.
  • Give it a name and leave the defaults.  Do not target it the AdminServer as we will target it in a moment.

Coherence Cluster

2. Create the WebLogic Clusters, place both your WLS clusters in the Coherence cluster and configure Coherence storage for each WLS cluster

  • Navigate to the Clusters link and create 2 clusters. StorageTier and ClientTier.
  • Leave the defaults as is.
  • Select the StorageTier cluster and click on the Coherence tab.
  • Select your newly created Coherence cluster and click Save.
  • Select Coherence Web Local Storage Enabled to ensure any managed servers in this cluster store Coherence*Web session data.
  • Click Save to continue.

Storage Tier

  • Select the ClientTier cluster and click on the Coherence tab.
  • Select your newly created Coherence cluster and click Save.
  • De-select Local Storage Enabled and click Save. We don’t want to actually store HTTP sessions in the client tier, but we want to be able to access them.

Client Tier

3. Create Managed Servers to populate each WLS cluster.

Note the managed servers added to each cluster will inherit their Coherence config form the cluster wide values which you set above. This means the Coherence managed servers added to the Storage Tier WLS cluster will be providing session storage while the Regular managed servers in the Client Tier WLS cluster will be coherence clients.

  • Navigate to the Servers link
  • Create a new managed server called client1 and assign it to the ClientTier as well as the machine you created. Set the listener port to 7005.
  • Create a new managed server called storage1 and assign it to the StorageTier as well as the machine you created. Set the listener port to 7007.
  • Clone storage1 and name it storage2 and change the listener port to 7009.
  • Start up you managed servers.

Managed Servers

Deployment

Now we need to Deploy applications which will demonstrate session fail-over and management features we have configured

  1. ClusterJSP – (optional) shows session failover.
  2. Sample-applications (optional) shows session management features

Deployment 1 ClusterJSP
Deploy ClusterJSP as a directory deployment rather than a archive deployment. This will make modifications of the deployment descriptors easier.  You can download the file required from here.

Deploy the Application

  • Unzip clusterjsp-ear.zip into your WLS domain applications directory (…/user_projects/applications)
    <wls install…>/applications/clusterjsp-ear/clusterjsp-war/WEB-INF/weblogic.xml
  • In the Admin. Console navigate to the Deployments page.
  • Click the Install button and navigate to the applications directory where you should find the clusterjsp-ear directory.
  • Click the select button to the left of the folder and click the Next button at the bottom of the page.
  • Leave Install as application selected and click Next.
  • Select ClientTier cluster and click Next.
  • Leave the defaults and click Finish.

Test the application

  • In a browser access the clusterjsp with the following url: http://yourhostname:7003/clusterjsp
  • Follow the instructions at the bottom of the displayed page.
  • To access the page from the other server in the client tier cluster change the the port number in the browser and hit enter. Notice the session attribute and value which you had added are not present because we have not yet enabled Coherence*Web.

Application Screenshot

Enable Coherence*Web Session Storage

  • Create a WLS deployment descriptor to enable Coherence*Web sessions by saving the text below into a new file called:
    <wls install…>/applications/clusterjsp-ear/clusterjsp-war/WEB-INF/weblogic.xml
<?xml version="1.0"?>

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">

  <session-descriptor>
    <persistent-store-type>coherence-web</persistent-store-type>
  </session-descriptor>

</weblogic-web-app>
  • In the Admin. Console navigate to the Deployments page.
  • Update the deployment by click the Select button next to the clusterjsp-ear application and click the Update button.
  • Repeat your previous test. This time you should see your Session attributes are present regardless of which client tier server you access.
  • Stop the servers one at a time in each tier and notice when the session data is no longer available.

Deployment 2 Large session sample-application

Next, deploy the sample-application.war (available from here) to just the ClientTier WebLogic Cluster.

The only step required to configure a web application to use Coherence*Web, select coherence-web as the persistence-store-type in WEB-INF/weblogic.xml as shown above. It’s that simple!

Next, run the application using the URL: http://your-ip-address:7005/sample-application and choose ‘Create Session’, then ‘Display Session’.  This is only a simple application with no real bells and whistles, to show you how to enable Coherence*Web for a web application.

You can see the output displays something similar to the following, which shows that Coherence is being used as the HTTP session store provider.

class: class weblogic.servlet.internal.session.CoherenceWebSessionData
sessionid: Vqi9nQtgCjpfO2F6FBHieVZV2vEmXfqF8Tyx6QDaQddqRhyKrFQM!502625314!1400916309965

The create.jsp file contains the following. Here we are just using the HTTP session and no Coherence specific code is used. You can experiment with the other links in the sample application.

<%@ page import="java.util.*"%>

<%
session = request.getSession(true);

out.println("class: " + session.getClass() + "<br/>");
out.println("sessionid: " + session.getId());
HashMap m = new HashMap();
m.put("a", 1);
m.put("b", 1);
session.setAttribute("test", m);
%>

Your web application is now using Coherence to store your HTTP sessions!

It’s very easy to scale out your HTTP session tier, just add another managed server to your StorageTier.

You can skip to the Conclusion below, or continue with the next section where I’ll show you how to install the Coherence JVisualVM Plug-in to view what’s going on under the covers.

Use the JVisualVM Plug-in from the Coherence Incubator Project to monitor the Coherence*Web session data

I’m using the Coherence JVisualVM Plug-in from the Coherence Incubator for viewing MBean information for the rest of this demo. You could just as well browse the MBean tree, but the Plug-in shows this in a nicer format.

For detailed information on how to install and connect jvisualVM to a WebLogic Server environment please see the Coherence Incubator site.

Install the Coherence VisualVM plugin brief steps

  • Download the latest pre-built plug-in module (NBM) from search.maven.org and save it to a local directory.
  • Start JVisualVM by running jvisualvm or jvisualvm.exe (for Windows) from the bin directory under your Java home.
  • Choose Tools -> Plugins.
  • Click on the ‘Downloads’ tab.
  • Click ‘Add Plugin’ and choose the file coherence-jvisualvm-12.2.0.nbm (from the location where you saved above).
  • Click ‘Install’ and follow the prompts to install.

Once installed, connect to either a remote or local JMX enabled Coherence cache server process using JMX

  • Restart jvisualvm with the following command (I have used UNIX style backslash for line continuation. If you are on Windows then please ensure the command is on one line.)
    $JAVA_HOME/bin/jvisualvm --cp:a \
    $WL_HOME/server/lib/wljmxclient.jar:$WL_HOME/server/lib/weblogic.jar \
    -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote \
    -J-Dcom.oracle.coherence.jvisualvm.disable.mbean.check=true
    
  • To create a connection right-click on either ‘Local’ or ‘Remote’ under the ‘Applications’ tree. Use the following for the connection URI and enter the credentials for the WebLogic Server Admin: (the following should contain no spaces)
    service:jmx:iiop://hostname:port/jndi/weblogic.management.mbeanservers.domainruntime
  • Once you have opened the newly created connection you will see the ‘Coherence Tab’.
  • For troubleshooting, see the Coherence Incubator site.

After connecting to the domain runtime mbean server, you should see the ‘Coherence’ tab displayed, select this tab and then the ‘Coherence*Web’ tab and you will see that there is a session that has been created.

Coherence*Web

If you then choose ‘Heavy Session’ in the sample web application, you will see the session overflow count go up as Coherence will store large attributes in a separate cache for optimised performance.

If you look at the ‘Caches’ tab, you will see the size of the session-storage and session-overflow caches are updated.

Coherence*Web Caches

Lastly, I used JMeter to create a load script that called the create.jsp and heavy.jsp to create sessions. You can see from the screenshot below, that you are able to view the number of sessions created and any session-reaping, which is cleaning up of old sessions.

More Sessions

Conclusion

It may have seemed that we went though a few steps above, but I wanted to show the evidence of the HTTP sessions begin stored Coherence*Web. The high-level steps to setup Coherence*Web are pretty straight forward:

  1. In your WebLogic domain, create a Coherence Cluster.
  2. Create a Client WebLogic Server Cluster and managed servers for your web apps and associate with the Coherence cluster as storage-disabled.
  3. Create a Storage WebLogic Server Cluster and managed servers for your data tier. Make this storage-enabled and also check ‘Coherence Web Local Storage Enabled‘.
  4. Update your WEB-INF/weblogic.xml to use coherence-web as persistence-store-type.
  5. Deploy your application and you are away.

Enjoy

 

 

Posted in Examples | Tagged , , | 2 Comments

Looking Forward to YOW! West in Perth

Finally I get the chance to attend a conference and not have to present!

YOW! West is on in Perth for the first time on May 13-14 and there are some great developer focussed topics.  Lets help support this conference and get it back for next year.

There is still enough time to get tickets: See http://west.yowconference.com.au

Posted in News | Tagged | 1 Comment

New Coherence GoldenGate HotCache Tutorial

A new tutorial about using Coherence GoldenGate HotCache is now available on OTN. This tutorial gives you a great introduction to GoldenGate HotCache and how to use it to keep Coherence caches in sync with back-end data sources.

Along with the above tutorial, there are some great data sheets, white pages and other information on Coherence available from OTN at http://www.oracle.com/technetwork/middleware/coherence/learnmore/index.html.

 

Posted in News | Tagged , , , , | Leave a comment

Using the NameService in Coherence 12.1.2

Introduction

In this post I would like to talk about a new feature in Coherence 12.1.2 called the NameService.  The NameService provides a greater level of flexibility in the way that you can configure and use proxy servers when you use Coherence*Extend.
See the 12.1.2 documentation for more detailed information.

Configuring Coherence*Extend in pre-12.1.2 Environments
Before 12.1.2, to configure a “Proxy Server” (or to be pedantic, a Proxy Service), you would configure a proxy-scheme in your cache configuration.

  <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <thread-count>5</thread-count>
      <acceptor-config>
        <tcp-acceptor>
          <local-address>
            <address>198.168.1.5<</address>
            <port>9099</port>
          </local-address>
        </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
    </proxy-scheme>

The above says we want to listen on address 198.168.1.5, port 9099 for incoming Coherence*Extend connections.

For a client you would then need to configure a remote-cache-scheme for your Coherence*Extend clients. An example is below:

<remote-cache-scheme>
  <scheme-name>extend-dist</scheme-name> 
  <service-name>ExtendTcpCacheService</service-name> 
  <initiator-config>
    <tcp-initiator> 
      <remote-addresses>
        <socket-address> 
          <address>198.168.1.5</address> 
          <port>9099</port>
        </socket-address> 
       </remote-addresses> 
       <connect-timeout>10s</connect-timeout>
    </tcp-initiator> 
    ...  
    </initiator-config> 
</remote-cache-scheme>

This configuration works fine, but it does mean we have to hard-code IP addresses in our server and client cache configuration files, as well as it makes it more difficult to add or remove proxy servers, without changing configuration.

Goals for the NameService
The NameService was introduced to help with some of the above challenges, and provide the following benefits in the way you configure Coherence*Extend:

  1. Remove addresses and ports from cache config for both the proxy-scheme and remote-* schemes.
  2. Provide the ability for multiple proxy services within a JVM be able to share a listen port.
  3. Support a large number of applications and proxies deployed to a single cluster node.
  4. Deploy proxies without a JVM restart.

 
Architecture
The NameService is a very light-weight service that runs on each node, irrespective of if there is a proxy server on that node. The NameService listens on ‘sub-port’ 3 of the unicast listen port. It is responsible for accepting requests from clients looking for a proxy service by name, and returning the address of the required proxy service.

The diagram below, outlines how the different components of the NameService work together.
NameService Architecture

When you startup a Coherence 12.1.2.0.1 cluster, (you need to use at least the first patch), you can see the name service starting up and listening on sub-port 3.

... ommitted ...
Group{Address=224.12.1.0, Port=12100, TTL=4}
MasterMemberSet(
  ThisMember=Member(Id=1, Timestamp=2014-03-21 11:59:11.573, Address=10.1.2.3:8088, MachineId=40577, 
Location=site:,machine:my-machine,process:55076, Role=CoherenceServer)
...
2014-03-21 11:59:14.899/4.588 Oracle Coherence GE 12.1.2.0.1 <Info> 
(thread=NameService:TcpAcceptor, member=1): TcpAcceptor now listening for connections on 10.1.2.3:8088.3

To define a proxy server that uses the NameService, you just need to provide an empty tcp-acceptor element. E.g. you don’t specify the listen port.

  <proxy-scheme>
    <service-name>ExtendTcpProxyService</service-name>
    <thread-count>5</thread-count>
    <acceptor-config>
      <!-- empty tcp-acceptor means to use the name service -->
      <tcp-acceptor/>      
    </acceptor-config>
    <autostart>true</autostart>
  </proxy-scheme>

When we startup a node with a proxy service defined, we will see the following messages:

  1. One indicating the NameService is started on sub-port 3 on the unicast listen address, and
  2. One indicating The proxy service starting up on an ephemeral sub-port.

The proxy service then registers its address with the NameService and is therefore known to all NameService members on all nodes.

2014-03-21 11:59:30.899/4.484 Oracle Coherence GE 12.1.2.0.1 <Info> (thread=NameService:TcpAcceptor, member=2): 
TcpAcceptor now listening for connections on 10.1.2.3:8090.3
...
2014-03-21 11:59:30.899/4.588 Oracle Coherence GE 12.1.2.0.1 <Info> (thread=Proxy:ExtendTcpProxyService:TcpAcceptor, member=2): 
TcpAcceptor now listening for connections on 10.1.2.3:8090.35545

The key thing is that we don’t actually need to know the address of the proxy server, just its service name.

Our client then defines the following remote-cache-scheme that defines the ‘proxy-service-name’ we want to connect to as well as an address-provider to find that address. The address provider is defined in the operational override file.

  <remote-cache-scheme>
    <scheme-name>extend-dist</scheme-name>
    <service-name>ExtendTcpCacheService</service-name>
    <!-- name of the remote proxy service to connect to -->
    <proxy-service-name>ExtendTcpProxyService</proxy-service-name>
    <initiator-config>
      <tcp-initiator>
        <name-service-addresses>
          <address-provider>extend-address-provider</address-provider>
        </name-service-addresses>
      </tcp-initiator>
      <outgoing-message-handler>
        <request-timeout>30s</request-timeout>
      </outgoing-message-handler>
    </initiator-config>
  </remote-cache-scheme>

The address provider effectively points to the unicast listen ports only, or WKA if you have defined this.

 <address-providers>
      <!-- this address provider of the cluster -->
      <address-provider id="extend-address-provider">
        <socket-address>
          <address >10.1.2.3</address>
          <port    >8088</port>
        </socket-address>
        <socket-address>
          <address >10.1.2.4</address>
          <port    >8088</port>
        </socket-address>
        <socket-address>
          <address >10.1.2.5</address>
          <port    >8088</port>
        </socket-address>
      </address-provider>
    </address-providers>

The client then connects to sub-port 3 (the NameService port) of one of the addresses in the address list and says its looking for a proxy service with the name ‘ExtendTcpProxyService’. The NameService will then (taking into account load balancing, etc) return the address of one of the proxy servers for the client to connect to.

In the messages below, you can see that the client originally connected to the NameService on sub-port 3 and then was directed to a proxy service with the appropriate name.

2014-03-21 12:59:30.899/4.588 Oracle Coherence GE 12.1.2.0.1 <D5> (thread=main, member=n/a): Connecting Socket to 10.1.2.3:8088.3
2014-03-21 12:59:30.899/4.588 Oracle Coherence GE 12.1.2.0.1 <Info> (thread=main, member=n/a): Connected Socket to 10.1.2.3:8088.3
2014-03-21 12:59:30.899/4.588 Oracle Coherence GE 12.1.2.0.1 <D5> (thread=main, member=n/a): Connecting Socket to 10.1.2.4:8089.35545
2014-03-21 12:59:30.899/4.588 Oracle Coherence GE 12.1.2.0.1 <Info> (thread=main, member=n/a): Connected Socket to 10.1.2.4:8089.35545

Summary
There are a fair few words above, but to summarise in dot-points.

  • In the nodes that proxy servers need to run on you specify an empty tcp-acceptor element.
  • On starting a node, the name service is started and listens on sub-port 3 of the unicast listen port (-Dtangosol.coherence.localport).
    Oracle Coherence GE 12.1.2.0.1  (thread=NameService:TcpAcceptor, member=4): 
    TcpAcceptor now listening for connections on 10.1.2.3:8088.3
  • The proxy service starts, registers its service-name with the NameService and listens on a random ephemeral sub-port of the unicast listen port. E.g.
    Oracle Coherence GE 12.1.2.0.1  (thread=Proxy:ExtendTcpProxyService:TcpAcceptor, member=4): 
    TcpAcceptor now listening for connections on 10.1.2.3:8088.60563
  • An address-provider is specified in the tangosol-coherence-override.xml file which points to the unicast-listen ports for the name service.
  • A client then uses the address provider client configuration to contact the name services and specifies the service-name of the proxy service it wishes to contact.
  • The name service returns the location of a proxy server to the client, and the client connects.

The NameService is great feature allowing you to simplify the management and setup of proxy servers to support Coherence*Extend.

I’m sure you will find it useful.

Posted in Examples | Tagged , , , | Leave a comment