I used to live in the SF Bay Area for near on six and a half years. Over that time, I got to see many of its beautiful areas and attractions. Being a runner and a bit of a cyclist, my favourite way to spend a few hours was always out on the wonderful trails and paths in and around the foothills.
With my Open World commitments over and a weekend on my hands, I've been able to get out and about and visit some of my favourite places all over again.
I went for a run on Thursday with my IronMan colleague Tug (well soon to be IronMan). We went out to Edgewood park -- and did a 40min run on an old favourite trail. Even at the end of summer, it was still a very nice place to run. It was dry and quite brown in patches, but the trails following a few of the little ridges there were all shaded by lovely trees and it was great to be back. Tug spanked me on the uphill portion of the run as evidenced by my Polar HRM which showed me running at 98% of my max heart rate on one portion of the trail.
I have a Polar Heart Rate Meter which I wear when I run and ride. It's got an amazing array of features which allow it to measure the heart rate of a wearer using a wireless transmitter and a chest strap. The version I have also works with a bike by placing a speed-sensor on the front fork. It then can keep track of the speed of the bike, allowing speed v heart rate comparisons to be made. Even better, it has an altitude sensor, so it can plot speed v heart rate v altirude -- which makes for very interesting viewing once a run/ride is over. Finally it allows the captured data from the watch to be uploaded to a computer so it can be easily viewed and stored.
On Saturday I went to what I think is my favourite run in the bay area -- Woodside. It starts on Woodside road at the Woodside school and winds its way through the quiet backroads until you reach Huddart County park. This place is sensational. The path I take follows a creek until it reaches the end and then climbs up and around a ridge. It then winds back down to the creek following a trail surrounded with majestic redwood trees, with the trail being soft underfoot from all of the fallen leaves from all of the trees. I could run there forever. The run then follows the way out to the starting point. It takes about 58min at a pretty good clip. When I lived here with my wife, we'd always do this around mid morning then head off to the Roberts store at Woodside for a Smoked Chicken foccacia for lunch. We'd have it every time we ran at Woodside. As much as I loved being back there this weekend, I missed running next to Jules, and my great mate, Dirty Rickster. He's worth an entire blog on his own.
Today I headed out to another favourite run -- Crystal Springs (or Sawyer Camp trail). It's a paved, marked (every 0.5 mi) trail which has an out and back trail of 6 miles. I took a shorter run today and just went out 3mi and turned around for a total of 6 miles. I ran quite hard today and pleasantly found that I was sitting quite comfortably on around 6:30 min/miles, giving me a total time of 39:15 for the 6 miles. I was very happy with that as my previous best time on that length was 39:46, which was in the midst of marathon training. So I was quite pleased -- pleased enough to go and get sushi and sapporro for dinner.
I have a few busy days at HQ to meet up with all the people I work with, before heading off back to Australia. I am not looking forward to the 15hr leg from SFO to SYD in cattle class. But I'll be stoked to see my little boy Sam and Jules at the airport when I get back.
26 September 2005
A trip to Oracle World in San Francisco
I am right in the middle of a visit back to Oracle HQ in Redwood Shores. The primary reason was to participate at Oracle World, but it also provides a good opportunity to hang around for a few days and catch up with the various engineering groups I work with.
Oracle World was a zoo this year. People everywhere. I guess that happens when you pull a few big companies into the fold and incorporate their user conferences into the one event. It's nice to see so many people around.
I didn't get to see any of the big keynotes -- we employees were relegated to booth bunnies, with the lucky ones of us also being able to present a session or two.
This year was quite relaxed for me as I only had one session to present. Normally I have 2 or more to deliver, quite often on a topic which is not core to my heart ... this year I co-shared a session on the new high availibility features we have in our 10.1.3 release. I covered off the new install functions as well as the new state replication framework.
Working on the booth is always a good experience -- we get to speak to all sorts of customers who usually have very interesting questions. I saw one chap this year who was walking around with his laptop all fired up and asking questions about how to get his EJB 3.0 application which he built inside of Eclipse to run on OC4J and work against a SqlServer database. After a bit of a chat he went away and came back a few hours later with it all sorted out -- EJB 3.0 beans running against SqlServer on OC4J. I then showed him which of our Ant tasks enables deployment operations to perform a bind-web operation to map a Web module to a web-site. Since he had Eclipse, it was trivial to add the new task to do the web binding since the Eclipse IDE shows tool-tips for Ant tasks -- it was beautiful to behold.
Oracle World was a zoo this year. People everywhere. I guess that happens when you pull a few big companies into the fold and incorporate their user conferences into the one event. It's nice to see so many people around.
I didn't get to see any of the big keynotes -- we employees were relegated to booth bunnies, with the lucky ones of us also being able to present a session or two.
This year was quite relaxed for me as I only had one session to present. Normally I have 2 or more to deliver, quite often on a topic which is not core to my heart ... this year I co-shared a session on the new high availibility features we have in our 10.1.3 release. I covered off the new install functions as well as the new state replication framework.
Working on the booth is always a good experience -- we get to speak to all sorts of customers who usually have very interesting questions. I saw one chap this year who was walking around with his laptop all fired up and asking questions about how to get his EJB 3.0 application which he built inside of Eclipse to run on OC4J and work against a SqlServer database. After a bit of a chat he went away and came back a few hours later with it all sorted out -- EJB 3.0 beans running against SqlServer on OC4J. I then showed him which of our Ant tasks enables deployment operations to perform a bind-web operation to map a Web module to a web-site. Since he had Eclipse, it was trivial to add the new task to do the web binding since the Eclipse IDE shows tool-tips for Ant tasks -- it was beautiful to behold.
15 September 2005
An OPMN discovery alternative
Multicast is the basic network infrastructure used when wiring together separate OPMN instances like I’ve been describing in these entries.
When you use opmnctl to configure the OPMN instances to work together, you specify a shared multicast address such as *234.1.1.1:6789. The * prefix tells OPMN that it works in discovery mode where it will add peers discovered from the shared communication bus, etc.
However if you don't want to use multicast, but still want to use this cool discovery approach to construct the OPMN topology (ie you don't want to use a fully connected OPMN cluster where each instance has a static pointer to each other instance which is hard to maintain) then you can use a slightly different approach.
What you do is to dedicate one specific instance as the discovery node and then configure each instance with the the OPMN address (host:remote_port) of the chosen discovery node. Each instance will then announce itself to the discovery node when it comes online, obtain the details of the other instances from the discovery node itself, and participatge in other various broadcast activities.
How does it work – let’s say I have 3 installs on 3 different servers. Each install has the default OPMN port set since it’s the single install on that server.
felt.au.oracle.com : remote=6200
giant.au.oracle.com : remote=6200
cervelo.au.oracle.com : remote=6200
We'll designate the “giant” server as our discovery node.
To setup a non multicast discovery cluster, you execute opmnctl on each one as follows:
opmnctl config topology update discover="giant.au.oracle.com:6200"
Note the missing "*" from the address and the use of the actual servername (or IP) with the OPMN request port -- instead of a multicast style address:port entry.
This will insert into the opmn.file the relevant entry which defines the giant.au.oracle.com:6200 instance as the discovery node.
Once you have done that on each instance, you should have an OPMN discoverable topology using direct TCP connections. Goodness never tasted so good.
The OPMN server running on the chosen discovery node (ie giant) should be started before any of the others, but besides that, you should then be able to use the this form of cluster in exactly the same way as if you'd used the multicast model.
When you use opmnctl to configure the OPMN instances to work together, you specify a shared multicast address such as *234.1.1.1:6789. The * prefix tells OPMN that it works in discovery mode where it will add peers discovered from the shared communication bus, etc.
However if you don't want to use multicast, but still want to use this cool discovery approach to construct the OPMN topology (ie you don't want to use a fully connected OPMN cluster where each instance has a static pointer to each other instance which is hard to maintain) then you can use a slightly different approach.
What you do is to dedicate one specific instance as the discovery node and then configure each instance with the the OPMN address (host:remote_port) of the chosen discovery node. Each instance will then announce itself to the discovery node when it comes online, obtain the details of the other instances from the discovery node itself, and participatge in other various broadcast activities.
How does it work – let’s say I have 3 installs on 3 different servers. Each install has the default OPMN port set since it’s the single install on that server.
felt.au.oracle.com : remote=6200
giant.au.oracle.com : remote=6200
cervelo.au.oracle.com : remote=6200
We'll designate the “giant” server as our discovery node.
To setup a non multicast discovery cluster, you execute opmnctl on each one as follows:
opmnctl config topology update discover="giant.au.oracle.com:6200"
Note the missing "*" from the address and the use of the actual servername (or IP) with the OPMN request port -- instead of a multicast style address:port entry.
This will insert into the opmn.file the relevant entry which defines the giant.au.oracle.com:6200 instance as the discovery node.
Once you have done that on each instance, you should have an OPMN discoverable topology using direct TCP connections. Goodness never tasted so good.
The OPMN server running on the chosen discovery node (ie giant) should be started before any of the others, but besides that, you should then be able to use the this form of cluster in exactly the same way as if you'd used the multicast model.
06 September 2005
Creating JDeveloper connections to OracleAS 10.1.3
Tip on deploying from JDeveloper
Deploying to an OracleAS instance from JDeveloper requires the creation of a connection to the target instance.
Using the Connection wizard, specify the Connection Type to be Oracle Application Server 10g 10.1.3. This ultimately constructs a JSR88 based connection to the desired server.
As you proceed through the connection wizard, step3 will ask you to enter the details of the target instance.
The hostname and OC4J instance name are obvious values.
But what about the OPMN port value? What does that value point at?
Well, what that is asking you for is the port setting for the OPMN request port. Since the OC4J instance is being managed by OPMN, it is OPMN itself that knows that the current port details are for the specified OC4J instance. So this connection model goes through OPMN to get the port values. Thus it requires the value of the OPMN request port*.
The default value used is 6003. Which is fine if you only have one OracleAS installation on the server. But if you have more than one installation, the OPMN request port of the second installation will be different.
In previous versions of the product, the only way to determine the OPMN request port was to actually open up the $ORACLE_HOME/opmn/conf/opmn.xml file for the OracleAS instance you want to connect to, and look at the port attributes in the file.
request="6035" />
With the actual 10.1.3 release, we have just implemented** a new opmnctl command to print out the port to use.
>opmnctl status –port
>duraace:6035
So all you need to do is to execute that command on the OracleAS instance you wish to connect to, and then feed that value into the JDeveloper connection details page.
*: The OPMN request port is a fixed port value defined automatically at install time. It doesn’t change over time. Unlike the actual OC4J RMI port which is allocated dynamically by OPMN when OC4J is started and is therefore subject to change if a port conflict needs to be avoided.
**: This command is not in the current Developer Preview 4 distribution. It will be in the production release.
Deploying to an OracleAS instance from JDeveloper requires the creation of a connection to the target instance.
Using the Connection wizard, specify the Connection Type to be Oracle Application Server 10g 10.1.3. This ultimately constructs a JSR88 based connection to the desired server.
As you proceed through the connection wizard, step3 will ask you to enter the details of the target instance.
The hostname and OC4J instance name are obvious values.
But what about the OPMN port value? What does that value point at?
Well, what that is asking you for is the port setting for the OPMN request port. Since the OC4J instance is being managed by OPMN, it is OPMN itself that knows that the current port details are for the specified OC4J instance. So this connection model goes through OPMN to get the port values. Thus it requires the value of the OPMN request port*.
The default value used is 6003. Which is fine if you only have one OracleAS installation on the server. But if you have more than one installation, the OPMN request port of the second installation will be different.
In previous versions of the product, the only way to determine the OPMN request port was to actually open up the $ORACLE_HOME/opmn/conf/opmn.xml file for the OracleAS instance you want to connect to, and look at the port attributes in the file.
With the actual 10.1.3 release, we have just implemented** a new opmnctl command to print out the port to use.
>opmnctl status –port
>duraace:6035
So all you need to do is to execute that command on the OracleAS instance you wish to connect to, and then feed that value into the JDeveloper connection details page.
*: The OPMN request port is a fixed port value defined automatically at install time. It doesn’t change over time. Unlike the actual OC4J RMI port which is allocated dynamically by OPMN when OC4J is started and is therefore subject to change if a port conflict needs to be avoided.
**: This command is not in the current Developer Preview 4 distribution. It will be in the production release.
05 September 2005
Cluster control pattern for opmnctl
Top usage tip for opmnctl
One of our OPMN engineers pointed out a blindingly obvious but very helpful usage pattern for opmnctl the other day. Which I’m dutifully passing on. Thanks Jon.
The opmn service/daemon is responsible for managing a process set within an OracleAS installation. At its simplest it starts/stops and actively monitors processes which make up an OracleAS instance.
As the notion of a cluster has evolved, the concept of a ‘scope’ has been introduced into opmnctl to extend the application of the command to a remote instance or the entire cluster, which I’ll loosely define as the collection of all known instances within the current OPMN topology.
The desired scope is applied as a prefix to the command :
>opmnctl @[cluster|remote]
Common Startup Pattern
A common use pattern is to issue the following command to start an OracleAS instace:
>opmnctl startall
Which causes the OPMN daemon/service itself to start, which then further starts each of the managed processes such as OC4J, Oracle HTTP Server, etc.
Since this use of opmnctl implicitly starts the OPMN daemon/service, it can’t have a scope applied to it.
Refined Startup Pattern
The prior opmnctl use pattern is equivalent to the following operations:
>opmnctl start
>opmnctl startproc
So what, it’s more typing for the same thing, right?
Well maybe.
Where it pays dividends is with the abilility to apply a scope command to the latter command, such as:
>opmnctl @cluster startproc
Or even perform commands on a specific remote instance:
>opmnctl @remote:j2ee_blue.duraace.au.oracle.com stopproc
So once you the OPMN daemon/service is running on each instance (which is a safe assumption in most cases) you can perform a significant set of operational commands across the entire cluster from one command line operation.
Getting used to treating OPMN as a fixed daemon/service provider and then using the scoped commands from opmnctl as a separate task can save you lots of time and effort, allowing you to use opmnctl command against whatever topology you can construct!
One of our OPMN engineers pointed out a blindingly obvious but very helpful usage pattern for opmnctl the other day. Which I’m dutifully passing on. Thanks Jon.
The opmn service/daemon is responsible for managing a process set within an OracleAS installation. At its simplest it starts/stops and actively monitors processes which make up an OracleAS instance.
As the notion of a cluster has evolved, the concept of a ‘scope’ has been introduced into opmnctl to extend the application of the command to a remote instance or the entire cluster, which I’ll loosely define as the collection of all known instances within the current OPMN topology.
The desired scope is applied as a prefix to the command :
>opmnctl @[cluster|remote]
Common Startup Pattern
A common use pattern is to issue the following command to start an OracleAS instace:
>opmnctl startall
Which causes the OPMN daemon/service itself to start, which then further starts each of the managed processes such as OC4J, Oracle HTTP Server, etc.
Since this use of opmnctl implicitly starts the OPMN daemon/service, it can’t have a scope applied to it.
Refined Startup Pattern
The prior opmnctl use pattern is equivalent to the following operations:
>opmnctl start
>opmnctl startproc
So what, it’s more typing for the same thing, right?
Well maybe.
Where it pays dividends is with the abilility to apply a scope command to the latter command, such as:
>opmnctl @cluster startproc
Or even perform commands on a specific remote instance:
>opmnctl @remote:j2ee_blue.duraace.au.oracle.com stopproc
So once you the OPMN daemon/service is running on each instance (which is a safe assumption in most cases) you can perform a significant set of operational commands across the entire cluster from one command line operation.
Getting used to treating OPMN as a fixed daemon/service provider and then using the scoped commands from opmnctl as a separate task can save you lots of time and effort, allowing you to use opmnctl command against whatever topology you can construct!
Subscribe to:
Posts (Atom)