How to change port number in JBoss App Server?

Source

As we all know that JBoss is running on port number 8080 as default. If you want to change the port number of your JBoss (jBoss 4) then thats also too easy. Just follow the following steps…

1. Open the JBoss Folder

2. Goto its Deploy folder.

3. Goto the jbossweb-tomcat55.sar

4. Find out the server.xml inside that folder. Actually this is the server configure file of the BuildIn Tomcat.

5. Find the folowing Tag

connector port="8080" address="${jboss.bind.address}"……

6. Change the port number here.

7. Restart the server.

I think the following image will help you better.

Understanding Java RMI: A Simple Tutorial

http://www.basilv.com/psd/blog/2006/java-rmi-tutorial

Posted by Basil Vandegriend on March 23rd, 2006. Categories: Java Tags: Java, RMI

I recently needed to write a simple java client-server application, and decided to implement the communication mechanism using Java RMI (Remote Method Invocation). I’ve used RMI in the past indirectly (i.e. when coding EJB session beans), but never directly, so I turned to Google to see what RMI tutorials were available. I quickly found several including the Sun RMI tutorial, but I was unsatisfied with all of them. Most of them seemed to be written in the Java 1.1 / 1.2 days, and the Java platform has changed a lot since then. I wasn’t sure if what I was reading reflected the best way of doing things in the latest version (JDK 5.0). Many of the tutorials also included extra details I didn’t need initially. After reading some of the tutorials, the relevant Java APIs, and doing some prototyping, I was able to get a simple RMI client-server application up and running. In the remainder of this article, I will present this application. I assume the use of JDK 5.0.

The simple application is a remote task executor. The client calls the server supplying a task (essentially a Runnable) to execute. The server then executes the task and returns the result to the client. A task is represented by the following interface:

public interface Task extends Serializable {
 public Object execute(Object argument);
}

(In order to use a Task remotely, its argument and return value must be serializable. But I am assuming that Task is also used in a non-remote setting, so have kept the method definition more generic.)

The first step is to implement a remote interface that the client will use when communicating with the server:

public interface RemoteTaskExecutor extends Remote {
 public Object executeTask(Task task, Serializable argument)
   throws RemoteException;
}

The next step is to implement the class that implements this interface and will execute on the server.

public class TaskExecutorServer extends UnicastRemoteObject
 implements RemoteTaskExecutor {

 public TaskExecutorServer() throws RemoteException {
   super();
 }

 public Object executeTask(Task task, Serializable argument) {
   return task.execute(argument);
 }
}

In versions of Java prior to 5.0, you then had to create a client stub class that implements the RemoteTaskExecutor interface and is called by the client (using the rmic compiler). However, in JDK 5.0 this is no longer necessary: a dynamic proxy (java.lang.reflect.Proxy) is automatically created instead. It is likely in a future version of Java that there will be a @Remote annotation to simplify constructing remoteable objects (i.e. removing the need for a separate remote interface). Such an annotation does not exist as of JDK 5.0, but the new EJB 3 specification is heading in that direction.

The next step is to configure the server to accept connections. The easiest way to do this is to start the RMI registry and register an instance of TaskExecutorServer with the registry using a specific name. Clients will be able to connect to this registry and obtain the remote proxy using this name. The registry can be started as a separate application (rmiregistry) or launched directly from the server application. Here’s the main method (in the TaskExecutorServer class) to do just that:

  public static final String REGISTRY_NAME =
   TaskExecutorServer.class.getName();

 public static void main(String[] args) throws Exception {
   int registryPortNumber = 1099;

   // Start RMI registry
   LocateRegistry.createRegistry(registryPortNumber);

   Naming.rebind(REGISTRY_NAME, new TaskExecutorServer());
   System.out.println("Server running...");
 }

The server application will not terminate, despite the main method completing execution. This is because the RMI code has started a daemon thread which is waiting to receive requests from clients. Each client request results in a new thread being spawned to handle the request. I found it amazing that so much functionality could be achieved in so few lines of code.

We’re not done yet - we need to provide the client. The client needs to connect to the RMI registry, obtain the remote proxy of the TaskExecutorServer, and then call it. We need to specify the host name and port number of the RMI registry in order to connect to it.

  public static void main(String[] args) throws Exception {
   String host = "localhost";
   int portNumber = 1099;
   String lookupName = "//" + host + ":" + portNumber + "/" +
     TaskExecutorServer.REGISTRY_NAME;
   RemoteTaskExecutor executor = (RemoteTaskExecutor)
     Naming.lookup(lookupName);

   System.out.println("Requesting task execution for " + args[0]);
   Object result = executor.executeTask(new TestTask(), args[0]);
   System.out.println("Task executed for " + result);
 }

The test task used in the above code just prints some information to the console:

public class TestTask implements Task {
 public Object execute(Object argument) {
   System.out.println("Executing task for " + argument);
   try {
     Thread.sleep(10000);
   } catch (InterruptedException e) {
     // Do nothing.
   }
   System.out.println("Executed task for " + argument);
   return argument;
 }
}

That completes the simple example of a Java RMI client-server application. I left out a few details. One important detail is that all arguments supplied to a remote method must be serializable. You may have noticed that the Task interface extends Serializable for just this reason. In the above example, when the TestTask instance is passed (serialized) to the server, the java VM on the server must have access to the TestTask class in order to deserialize the instance. Therefore, the TestTask class must be on the classpath for the server application. There may be times where you want to avoid this limitation: perhaps you don’t want to redeploy and restart your server application whenever you implement a new Task to execute. Java RMI supports this by allowing the class definition itself to be sent (serialized) from the client to the server. However, since this is a security risk (it allows arbitrary code to be executed on the server), a security manager is required to explicitly allow this. The code to set this up is quite simple, and just needs to be called on the server before calling Naming.rebind().

if (System.getSecurityManager() == null) {
 System.setSecurityManager(new RMISecurityManager());
}

If you want to shut your server down, you just need to call Naming.unbind() passing in the name you used to register your code. (i.e. REGISTRY_NAME in the example above.) This call must be made from the server.

That concludes my RMI tutorial. I hope you found it helpful.

Hibernate and Logging

http://www.basilv.com/psd/blog/2008/hibernate-and-logging

Posted by Basil Vandegriend on February 23rd, 2008. Categories: Java Tags: Hibernate, Java, log4j, software development

Hibernate tries to hide the details of dealing with relational databases, but it is at best a leaky abstraction. At its most basic level, Hibernate is a framework that issues SQL commands to the database. Sometimes it does not do what you would expect or want (more on that in future articles). Therefore it is very useful at times to monitor or review the SQL being produced by Hibernate. The book Java Persistence with Hibernate covers this topic primarily by discussing the show.sql hibernate configuration property which writes generated SQL to the console. I have found this far too limiting: I instead want the SQL logged in my application’s log (i.e. as produced by log4j) to receive all the advantages that a central logging system can provide. This can be accomplished by turning on DEBUG logging for the logging context org.hibernate.SQL. If you are using log4j, add the following line to your log4j.properties file:

log4j.logger.org.hibernate.SQL=DEBUG

One limitation of this SQL logging is that it reports the SQL statement but not the values of the parameters. Since Hibernate almost always uses prepared statements with parameters, this is often an annoying limitation. Fortunately, Hibernate does allow the logging of parameter values: turn on DEBUG logging for the logging context org.hibernate.type. Unfortunately, this results in very verbose logs since each parameter value for each query is a separate log entry. A sample log entry for a single insert statement is shown below.

07 Feb 2008 13:30:52,596 DEBUG insert into example.customer (CATEGORY,
CREATE_USER_ID, CREATE_TIMESTAMP, UPDATE_USER_ID, UPDATE_TIMESTAMP, OID)
values (?, ?, ?, ?, ?, ?) - org.hibernate.SQL [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding 'S' to parameter: 1 -
hibernate.type.StringType [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding 'junit test' to parameter: 2 -
hibernate.type.StringType [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding '2008-02-07 13:30:52' to parameter: 3 -
hibernate.type.DbTimestampType [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding '2008-02-07 13:30:52' to parameter: 4 -
hibernate.type.TimestampType [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding 'junit test' to parameter: 5 -
hibernate.type.StringType [main] [44513 ms]

07 Feb 2008 13:30:52,596 DEBUG binding '2691102' to parameter: 6 -
hibernate.type.LongType [main] [44513 ms]

I much prefer the way that Spring JDBC logs SQL statements – both the SQL and the list of parameter values are logged as a single statement. If you know how to do this in Hibernate, I would appreciate hearing from you.

Hibernate uses Apache’s commons-logging to abstract the actual logging mechanism: typically either log4j or Java logging (introduced in Java 1.4). I always use log4j myself, and normaly including the log4j jar file in the classpath is sufficient to have commons-logging use log4j. When running code in an application server, however, this is not always the case. I have had issues with both WebSphere and WebLogic application servers configuring commons-logging for some other behavior and having that setting ‘leak’ into my application. As a result, instead of having log messages from Hibernate appear in the application log along with the rest of the log statements produced directly with the log4j API, the Hibernate log messages appear elsewhere. In WebSphere 6.1, I had them going to the console (standard out). The simplest solution is to add a configuration file named commons-logging.properties to the root of your application’s classpath with the following content that instructs commons-logging to use log4j for logging:

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4jLogger

This article is one of a series on Hibernate Tips & Tricks.

The Decorator Pattern

From http://pragmaticcraftsman.com/design_patterns/

September 14, 2006 | Comments (0) »

I've been in the dark as far as the Decorator pattern is concerned. I knew, in principle, how it works, but I can see that my understanding was very incomplete. Plus, I never had a chance to use it. While reading the Head First Design Patterns book, I discovered something basic that: when you wrap an object several times and then call a method on it, it will be called as many times as it was wrapped. The trick? Keep a reference to the object -- you're creating a chain.

Let me go through this step by step. By example. This is the book's example, the Starbuzz Coffee decorator.

A simple interface.

public interface Beverage {

public String getDescription();

public BigDecimal getCost();

}

We have several coffee types, Dark Roast being one of them.

public class DarkRoast implements Beverage {

public BigDecimal getCost() {

return new BigDecimal("1.55");

public String getDescription() {

return "Dark Roast";

}

}

When ordering coffee, you can pick a coffee type (Dark Roast, Latte, etc), and you can also add on to the coffee. For instance, you can add a whip cream on top, or add a shot of expresso to it. Which, of course, adds to the price. You could extend Beverage with all of the types, but that's too many classes. Here's where the decorator pattern comes into play.

Here's the solution. You define the AddOnDecorator and extend it with the different add ons.

/** It's just an empty class */

public abstract class AddOnDecorator implements Beverage { }

public class Expresso extends AddOnDecorator {

Beverage beverage;

public Expresso(Beverage beverage) {

this.beverage = beverage;

}

public BigDecimal getCost() {

return new BigDecimal("0.25").add(beverage.getCost());

}

public String getDescription() {

return beverage.getDescription() + ", with Expresso";

}

public class Whip extends AddOnDecorator {

Beverage beverage;

public Whip(Beverage beverage) {

this.beverage = beverage;

public BigDecimal getCost() {

return new BigDecimal("0.10").add(beverage.getCost());

public String getDescription() {

return beverage.getDescription() + ", Whipped";

}

}

public class StarbuzzCoffee {

public static void main(String[] args) {

Beverage darkRoast = new DarkRoast();

darkRoast = new Expresso(darkRoast);

darkRoast = new Whip(darkRoast);

System.out.println(darkRoast.getDescription() + " costs "

+ darkRoast.getCost());

}

}

When I first looked at the code, I was confused. I thought that new Whip(...) would just override it, right?

This is what gets printed: Dark Roast, with Expresso, Whipped costs 1.90

You get the beverage you want (DarkRoast), you pass it to the Expresso wrapper, which in turn passes it to the Whip wrapper.

First the Expresso wrapper is called, it receives the dark roast beverage. Then the dark roast is passed again to the Whip wrapper. If you look closely (and this is a little confusing), when an Expresso is instantiated, it receives the beverage and makes a local copy (so it is never lost). Essentially, a chain is made. When the action on the final object is made, the chain is traversed and the beverage object is passed around. That's how this pattern works. (Wow, I learn something (basic) every day. :-))

The Decorator pattern is cool. It rocks. :-) It lets you keep adding functionality and still keep the objects cohesive (as you're not bloating the objects). No coupling as well. Nice.

Slashdot's Setup, Hardware

As part of our 10-Year anniversary coverage, we intend to update our insanely dated FAQ entry that describes our system setup. Today is Part 1 where we talk mostly about the hardware that powers Slashdot. Next week we'll run Part 2 where we'll talk mostly about Software. Read on to learn about our routers, our databases, our webservers and more. And as a reminder, don't forget to bid on our charity auction for the EFF and if you are in Ann Arbor, our anniversary party is tomorrow night.

CT:Most of the following was written by Uriah Welcome, famed sysadmin extraordinaire, responsible for our corporate intertubes. He Writes...

Many of you have asked about the infrastructure that supports your favorite time sink... err news site. The question even reached the top ten questions to ask CmdrTaco. So I've been asked to share our secrets on how we keep the site up and running, as well as a look towards the future of Slashdot's infrastructure. Please keep in mind that this infrastructure not only runs Slashdot, but also all the other sites owned by SourceForge, Inc.: SourceForge.net, Thinkgeek.com, Freshmeat.net, Linux.com, Newsforge.com, et al.

Well, let's begin with the most boring and basic details. We're hosted at a Savvis data center in the Bay Area. Our data center is pretty much like every other one. Raised floors, UPSs, giant diesel generators, 24x7 security, man traps, the works. Really, once you've seen one class A data center, you've seen them all. (CT: I've still never seen one. And they won't let us take pictures. Boo savvis.)

Next, our bandwidth and network. We currently have two Active-Active Gigabit uplinks; again nothing unique here, no crazy routing, just symmetric, equal cost uplinks. The uplinks terminate in our cage at a pair of Cisco 7301s that we use as our gateway/border routers. We do some basic filtering here, but nothing too outrageous; we tier our filtering to try to spread the load. From the border routers, the bits hit our core switches/routers, a pair of Foundry BigIron 8000s. They have been our workhorses throughout the years. The BigIron 8000s have been in production since we built this data center in 2002 and actually, having just looked at it... haven't been rebooted since. These guys used to be our border routers, but alas... their CPUs just weren't up to the task after all these years and growth. Many machines plug directly into these core switches, however for certain self contained racks we branch off to Foundry FastIron 9604s. They are basically switches and do nothing but save us ports on the cores.

Now onto the meat: the actual systems. We've gone through many vendors over the years. Some good, some...not so much. We've had our share of problems with everyone. Currently in production we have the following: HP, Dell, IBM, Rackable, and I kid you not, VA Linux Systems. Since this article is about Slashdot, I'll stick to their hardware. The first hop on the way to Slashdot is the load balancing firewalls, which are a pair of Rackable Systems 1Us; P4 Xeon 2.66Gz, 2G RAM, 2x80GB IDE, running CentOS and LVS. These guys distribute the traffic to the next hop, which are the web servers.

Slashdot currently has 16 web servers all of which are running Red Hat 9. Two serve static content: javascript, images, and the front page for non logged-in users. Four serve the front page to logged in users. And the remaining ten handle comment pages. All web servers are Rackable 1U servers with 2 Xeon 2.66Ghz processors, 2GB of RAM, and 2x80GB IDE hard drives. The web servers all NFS mount the NFS server, which is a Rackable 2U with 2 Xeon 2.4Ghz processors, 2GB of RAM, and 4x36GB 15K RPM SCSI drives. (CT: Just as a note, we frequently shuffle these 16 servers from one task to another to handle changes in load or performance. Next week's software story will explain in much more detail exactly what we do with those machines. Also as a note- the NFS is read-only, which was really the only safe way to use NFS around 1999 when we started doing it this way.)

Besides the 16 web servers, we have 7 databases. They currently are all running CentOS 4. They breakdown as follows: 2 Dual Opteron 270's with 16GB RAM, 4x36GB 15K RPM SCSI Drives These are doing multiple-master replication, with one acting as Slashdot's single write-only DB, and the other acting as a reader. We have the ability to swap their functions dynamically at any time, providing an acceptable level of failover.

2 Dual Opteron 270's with 8GB RAM, 4x36GB 15K RPM SCSI Drives These are Slashdot's reader DBs. Each derives data from a specific master database (listed above). The idea is that we can add more reader databases as we need to scale. These boxes are barely a year old now — and still are plenty fast for our needs.

Lastly, we have 3 Quad P3 Xeon 700Mhz with 4GB RAM, 8x36GB 10K RPM SCSI Drives which are sort of our miscellaneous 'other' boxes. They are used to host our accesslog writer, an accesslog reader, and Slashdot's search database. We need this much for accesslogs because moderation and stats require a lot of CPU time for computation.

And that is basically it, in a nutshell. There isn't anything too terribly crazy about the infrastructure. We like to keep things as simple as possible. This design is also very similar to what all the other SourceForge, Inc. sites use, and has proved to scale quite well.

Today we have Part 2 in our exciting 2 part series about the infrastructure that powers Slashdot. Last week Uriah told us all about the hardware powering the system. This week, Jamie McCarthy picks up the story and tells us about the software... from pound to memcached to mysql and more. Hit that link and read on.

The software side of Slashdot takes over at the point where our load balancers -- described in Friday's hardware story -- hand off your incoming HTTP request to our pound servers.

Pound is a reverse proxy, which means it doesn't service the request itself, it just chooses which web server to hand it off to. We run 6 pounds, one for HTTPS traffic and the other 5 for regular HTTP. (Didn't know we support HTTPS, did ya? It's one of the perks for subscribers: you get to read Slashdot on the same webhead that admins use, which is always going to be responsive even during a crush of traffic -- because if it isn't, Rob's going to breathe down our necks!)

The pounds send traffic to one of the 16 apaches on our 16 webheads -- 15 regular, and the 1 HTTPS. Now, pound itself is so undemanding that we run it side-by-side with the apaches. The HTTPS pound handles SSL itself, handing off a plaintext HTTP request to its machine's apache, so the apache it redirects traffic to doesn't need mod_ssl compiled in. One less headache! Of our other 15 webheads, 5 also run a pound, not to distribute load but just for redundancy.

(Trivia: pound normally adds an X-Forwarded-For header, which Slash::Apache substitutes for the (internal) IP of pound itself. But sometimes if you use a proxy on the internet to do something bad, it will send us an X-Forwarded-For header too, which we use to try to track abuse. So we patched pound to insert a special X-Forward-Pound header, so it doesn't overwrite what may come from an abuser's proxy.)

The other 15 webheads are segregated by type. This segregation is mostly what pound is for. We have 2 webheads for static (.shtml) requests, 4 for the dynamic homepage, 6 for dynamic comment-delivery pages (comments, article, pollBooth.pl), and 3 for all other dynamic scripts (ajax, tags, bookmarks, firehose). We segregate partly so that if there's a performance problem or a DDoS on a specific page, the rest of the site will remain functional. We're constantly changing the code and this sets up "performance firewalls" for when us silly coders decide to write infinite loops.

But we also segregate for efficiency reasons like httpd-level caching, and MaxClients tuning. Our webhead bottleneck is CPU, not RAM. We run MaxClients that might seem absurdly low (5-15 for dynamic webheads, 25 for static) but our philosophy is if we're not turning over requests quickly anyway, something's wrong, and stacking up more requests won't help the CPU chew through them any faster.

All the webheads run the same software, which they mount from a /usr/local exported by a read-only NFS machine. Everyone I've ever met outside of this company gives an involuntary shudder when NFS is mentioned, and yet we haven't had any problems since shortly after it was set up (2002-ish). I attribute this to a combination of our brilliant sysadmins and the fact that we only export read-only. The backend task that writes to /usr/local (to update index.shtml every minute, for example) runs on the NFS server itself.

The apaches are versions 1.3, because there's never been a reason for us to switch to 2.0. We compile in mod_perl, and lingerd to free up RAM during delivery, but the only other nonstandard module we use is mod_auth_useragent to keep unfriendly bots away. Slash does make extensive use of each phase of the request loop (largely so we can send our 403's to out-of-control bots using a minimum of resources, and so your page is fully on its way while we write to the logging DB).

Slash, of course, is the open-source perl code that runs Slashdot. If you're thinking of playing around with it, grab a recent copy from CVS: it's been years since we got around to a tarball release. The various scripts that handle web requests access the database through Slash's SQL API, implemented on top of DBD::mysql (now maintained, incidentally, by one of the original Slash 1.0 coders) and of course DBI.pm. The most interesting parts of this layer might be:

(a) We don't use Apache::DBI. We use connect_cached, but actually our main connection cache is the global objects that hold the connections. Some small chunks of data are so frequently used that we keep them around in those objects.

(b) We almost never use statement handles. We have eleven ways of doing a SELECT and the differences are mostly how we massage the results into the perl data structure they return.

(c) We don't use placeholders. Originally because DBD::mysql didn't take advantage of them, and now because we think any speed increase in a reasonably-optimized web app should be a trivial payoff for non-self-documenting argument order. Discuss!

(d) We built in replication support. A database object requested as a reader picks a random slave to read from for the duration of your HTTP request (or the backend task). We can weight them manually, and we have a task that reweights them automatically. (If we do something stupid and wedge a slave's replication thread, every Slash process, across 17 machines, starts throttling back its connections to that machine within 10 seconds. This was originally written to handle slave DBs getting bogged down by load, but with our new faster DBs, that just never happens, so if a slave falls behind, one of us probably typed something dumb at the mysql> prompt.)

(e) We bolted on memcached support. Why bolted-on? Because back when we first tried memcached, we got a huge performance boost by caching our three big data types (users, stories, comment text) and we're pretty sure additional caching would provide minimal benefit at this point. Memcached's main use is to get and set data objects, and Slash doesn't really bottleneck that way.

Slash 1.0 was written way back in early 2000 with decent support for get and set methods to abstract objects out of a database (getDescriptions, subclassed _wheresql) -- but over the years we've only used them a few times. Most data types that are candidates to be objectified either are processed in large numbers (like tags and comments), in ways that would be difficult to do efficiently by subclassing, or have complicated table structures and pre- and post-processing (like users) that would make any generic objectification code pretty complicated. So most data access is done through get and set methods written custom for each data type, or, just as often, through methods that perform one specific update or select.

Overall, we're pretty happy with the database side of things. Most tables are fairly well normalized, not fully but mostly, and we've found this improves performance in most cases. Even on a fairly large site like Slashdot, with modern hardware and a little thinking ahead, we're able to push code and schema changes live quickly. Thanks to running multiple-master replication, we can keep the site fully live even during blocking queries like ALTER TABLE. After changes go live, we can find performance problem spots and optimize (which usually means caching, caching, caching, and occasionally multi-pass log processing for things like detecting abuse and picking users out of a hat who get mod points).

In fact, I'll go further than "pretty happy." Writing a database-backed web site has changed dramatically over the past seven years. The database used to be the bottleneck: centralized, hard to expand, slow. Now even a cheap DB server can run a pretty big site if you code defensively, and thanks to Moore's Law, memcached, and improvements in open-source database software, that part of the scaling issue isn't really a problem until you're practically the size of eBay. It's an exciting time to be coding web applications.

Building a better query

For most Google searches, simply typing what you want to find does the job. If you want to refine your search, however, these suggestions from our quality team may help.

Choose your words carefully Use words likely to appear on the pages you want USE [ Idaho luxury hotel ] NOT [ a fancy place to stay in Idaho ] USE [ tutorial ] [ introduction ] or [ overview ] NOT [ help ] Be specific USE [ antique metal soldiers ] NOT [ old toys ] Be brief Google limits your query to 10 words maximum For best results, use a few very precise words Good grammar counts Use the uppercase term OR to create logical choices [ lemur relocation program OR programs ] [ vacation rental Oahu OR Maui ] Use a minus sign ("-") to show only pages without specific words (do not include spaces) [ green jaguar –football ] Google ignores some common words. To force inclusion, use a "+" (do not include spaces) [ +in +and out ] To find only pages with a set of words in a specific order, put them in quotes [ "to be or not to be" ]

Restrict your search

---

Site: restricts your search to a specific site or domain and can be used to eliminate commercial results from your query

[ research fellows site:IBM.com ]
[ allergies site:.edu ]
[ volunteering site:.org ]
[ 1040 site:irs.gov ]

Use link: to see what sites link to a specific page

[ link:googlestore.com ]

Use info: for links to more info about a page (e.g., pages that mention the URL)

[ info:google.com ]

Enter an address with city and state or zip code for a link to a map

[ 2400 Bayshore Mountain View CA ]

Search specialized areas like Google Groups for advice and suggestions or Google Images for photos

Advanced Operators

Google supports several advanced operators, which are query words that have special meaning to Google. Typically these operators modify the search in some way, or even tell Google to do a totally different type of search. For instance, "link:" is a special operator, and the query [link:www.google.com] doesn't do a normal search but instead finds all web pages that have links to www.google.com.

Several of the more common operators use punctuation instead of words, or do not require a colon. Among these operators are OR, "" (the quote operator), - (the minus operator), and + (the plus operator). More information on these types of operators is available on the Basics of Search page. Many of these special operators are accessible from the Advanced Search page, but some are not. Below is a list of all the special operators Google supports.

Alternate query types

cache:		If you include other words in the query, Google will highlight those words within the cached document. For instance, [cache:www.google.com web] will show the cached content with the word "web" highlighted. This functionality is also accessible by clicking on the "Cached" link on Google's main results page. The query [cache:] will show the version of the web page that Google has in its cache. For instance, [cache:www.google.com] will show Google's cache of the Google homepage. Note there can be no space between the "cache:" and the web page url.
link:		The query [link:] will list webpages that have links to the specified webpage. For instance, [link:www.google.com] will list webpages that have links pointing to the Google homepage. Note there can be no space between the "link:" and the web page url. This functionality is also accessible from the Advanced Search page, under Page Specific Search > Links.
related:		The query [related:] will list web pages that are "similar" to a specified web page. For instance, [related:www.google.com] will list web pages that are similar to the Google homepage. Note there can be no space between the "related:" and the web page url. This functionality is also accessible by clicking on the "Similar Pages" link on Google's main results page, and from the Advanced Search page, under Page Specific Search > Similar.
info:		The query [info:] will present some information that Google has about that web page. For instance, [info:www.google.com] will show information about the Google homepage. Note there can be no space between the "info:" and the web page url. This functionality is also accessible by typing the web page url directly into a Google search box.

Other information needs

define:		The query [define:] will provide a definition of the words you enter after it, gathered from various online sources. The definition will be for the entire phrase entered (i.e., it will include all the words in the exact order you typed them).
stocks:		If you begin a query with the [stocks:] operator, Google will treat the rest of the query terms as stock ticker symbols, and will link to a page showing stock information for those symbols. For instance, [stocks: intc yhoo] will show information about Intel and Yahoo. (Note you must type the ticker symbols, not the company name.) This functionality is also available if you search just on the stock symbols (e.g. [ intc yhoo ]) and then click on the "Show stock quotes" link on the results page.

Query modifiers

site:		If you include [site:] in your query, Google will restrict the results to those websites in the given domain. For instance, [help site:www.google.com] will find pages about help within www.google.com. [help site:com] will find pages about help within .com urls. Note there can be no space between the "site:" and the domain. This functionality is also available through Advanced Search page, under Advanced Web Search > Domains.
allintitle:		If you start a query with [allintitle:], Google will restrict the results to those with all of the query words in the title. For instance, [allintitle: google search] will return only documents that have both "google" and "search" in the title. This functionality is also available through Advanced Search page, under Advanced Web Search > Occurrences.
intitle:		If you include [intitle:] in your query, Google will restrict the results to documents containing that word in the title. For instance, [intitle:google search] will return documents that mention the word "google" in their title, and mention the word "search" anywhere in the document (title or no). Note there can be no space between the "intitle:" and the following word. Putting [intitle:] in front of every word in your query is equivalent to putting [allintitle:] at the front of your query: [intitle:google intitle:search] is the same as [allintitle: google search].
allinurl:		If you start a query with [allinurl:], Google will restrict the results to those with all of the query words in the url. For instance, [allinurl: google search] will return only documents that have both "google" and "search" in the url. Note that [allinurl:] works on words, not url components. In particular, it ignores punctuation. Thus, [allinurl: foo/bar] will restrict the results to page with the words "foo" and "bar" in the url, but won't require that they be separated by a slash within that url, that they be adjacent, or that they be in that particular word order. There is currently no way to enforce these constraints. This functionality is also available through Advanced Search page, under Advanced Web Search > Occurrences.
inurl:		If you include [inurl:] in your query, Google will restrict the results to documents containing that word in the url. For instance, [inurl:google search] will return documents that mention the word "google" in their url, and mention the word "search" anywhere in the document (url or no). Note there can be no space between the "inurl:" and the following word. Putting "inurl:" in front of every word in your query is equivalent to putting "allinurl:" at the front of your query: [inurl:google inurl:search] is the same as [allinurl: google search].

---

Also check these Google pages for more tips:

---

• Advanced search page
  http://www.google.com/advanced_search
• Google Help Central
  http://www.google.com/help/index.html
• Other advanced search tips
  http://www.google.com/help/operators.html

Run Commands For Windows XP

For some specific reasons Microsoft chose to use commands for many of its useful features. Unfortunately many such commands aren’t know to the general user and they fail to use some of the very juicy features of Microsoft Windows.

Here I have collected some of the commands which will help you access those hidden features. You need to type these commands in the Run dialog box which you find in Start Menu.

• command OR cmd - Opens the DOS prompt or as some people call it, the command prompt.
• compmgmt.msc - Opens the computer management console.
• calc - Although this is available somewhere in the start menu, still I think you should know it.
• dxdiag - It stands for DirectX Diagnostic. The DirectX utility can be used to show a computer’s hardware specs as well as test DirectX software such as sound and video.
• dfrg.msc - Disk fragmentation.
• devmgmt.msc - Device manager.
• diskmgmt.msc - Disk management.
• eventvwr.msc - Event viewer.
• fsmgmt.msc - Access shared folders in one window.
• gpedit.msc - Manage Group policies.
• iexplore - In case you want the Internet Explorer icon.
• lusrmgr.msc - Local users and groups.
• msconfig - System Configuration Utility.
• msinfo32 - System Information.
• mailto: - Opens default email client.
• perfmon.msc - Performance monitor.
• regedit - Registry Editor.
• rsop.msc - Resultant set of policies.
• secpol.msc - Local security settings.
• services.msc - Various Services.
• sysedit - System Edit.
• win.ini - Windows Loading Information.
• winver - Shows current version of windows.