A Spiritual Feast

I am excited for the 2012 LDS spring conference sessions.

You can listen or watch them for free online. Consider accepting my invitation to attend conference and pull up your own chair to a spiritual feast.

Performance settings for production weblogic deployments

Put this in the weblogic.xml under WEB-INF folder: 

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.oracle.com/technology/weblogic/servers/wls810/dtd/weblogic810-web-jar.dtd">

<weblogic-web-app>

<container-descriptor>
<servlet-reload-check-secs>-1</servlet-reload-check-secs>
</container-descriptor>

</weblogic-web-app>

For JSPs you can also set this in weblogic.xml:

<jsp-descriptor>
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>-1</param-value>
</jsp-param>
</jsp-descriptor>

Unless you are altering servlet code and JSPs on the fly in production (bad idea), there is no need to ever check for changes. These two settings can help with performance because without them, Weblogic will have periodic threads blocking
requests to poll the filesystem for Servlet or JSP changes.

So by default in thread dumps you will see one or more of this sort of thing:

waiting for monitor entry [c4f7f000..c4f7fc28]
     at weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:771)

unless you disable that like shown above.

8 reasons why your browser does NOT send the cookie as part of the request

There are several reasons why a cookie you attempted to set on a remote client browser as part of a HTTP response is NOT sent back on the next request:

1. The domain of the request does not match the cookie's domain attribute
2. The path of the request does not match the cookie's path attribute
3. The cookie has expired
4. The cookie was set the secure attribute and the client's request was plain text HTTP.
5. The cookie was set with the httpOnly attribute and the client's request was not HTTP/HTTPS (e.g. you used FTP).
6. The client has disabled cookies globally or specifically for your domain.
7. The client deleted or cleared the cookie that was set before the next request was made.
8. The client's browser does not trust the SSL certificate used to sign your site and you are trying to use HTTPS communication.

Your domain of the request does not match the cookie's domain attribute

This one appears to be the most obvious of them all but does have a small gotcha. A cookie set for domain www.google.com will not be sent for a request to www.yahoo.com. We can understand that, but it will also not be sent for mail.google.com! The domain mail.google.com does not match www.google.com, so cookies set on one do not affect requests for the other. So when setting cookies that should be sent for all sub-domains: use .domain.com as the cookie's domain attribute, i.e. leave off the sub-domain (www) and just lead with the . prefix.

Your path of the request does not match the cookie's path attribute

If you set the path to /, all paths on the domain are going to send the cookie with the request, even if the request is for an image.. So use path wisely to avoid unnecessary overhead in your requests, especially if you are a heavy user of cookies. you only get one cookie path, make it count. You will be ding'd on Yslow if you don't avoid sending cookie info for images.

Your cookie has expired

Duh. Don't expect old cookies to join your request party. Be careful of short expiration on cookies, they may go stale before they are even set.

Your client has disabled cookies globally or for your specific domain

This is why it is important to document the requirements for your application. If you need cookies enabled (or even better detect that cookies are not enabled), tell the user to enable them (and how to enabled them) in a big red alert box with a flashing siren.

This is my list, do you have other reasons to add?