Porblem Servlet Clustering

Hi All,
I am usning OC4J2.0 which comes with Jdev release candidate in WIN-NT platform.
I have configured the servlet clustering with oc4j2, but there's problem.
I have configured a cluster,Node A and Node B in the Island 1, all in the same machine, but have different server port.
Now the problem is,
1. When there is no session, it works well, if one is down, request is directed to another. But if i have session, the request is getting redirected to another node(if one is down), whereas the session is not.
2. I have included cluster-config tag inside orion-web.xml.But i didnt give any port number and ip address for multi casting.Is the default port number 9127 has anything to do with JMS port number? 'coz i have given 9127 to Node A and 9128 to Node B
( i have included <distributable /> tag inside web.xml....)
Same application works fine with session replications, when i configure them in two different machines.
Thanx and Regards
--Venky                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

Hi Folks
I solved clustering with session replication problem...:-)
For doing this you have to add an attribute
load-on-startup="true" for "web-app" element in default-web-app.xml/http-web-site.xml..Unfortunately this has not been documented anywhere...:-(
This attribute will make application to get started while server starts up and session also gets replicated.....
Cheers
--Venky                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Similar Messages

  • Problem in Servlet Clustering !

    Hi,
              I have configured the WebLogic Server for Servlet Clustering. But how do I know that the servlet configuration is working?
              I am using WebLogic 6.1 (sp2), I am using two different machines (NT WorkStations) as members of a cluster. I invoke the jsp (or any servlet) with the following url:
              http://ipofoneoftheclusteredservers:7005/examplesWebApp/HelloWorld.jsp
              or with
              http://ipoftheotherclusteredserver:7005/examplesWebApp/HelloWorld.jsp
              both of these give results, but how do i test this setup for clustering??
              let me know !
              -dee
              

              Thanks for the reply. Can you help me a little more? Currently i am stuck up while
              doing clustering.
              The Scenario i am using is as follows :
              I have three machine: two as the servers participating in the clustering with
              ip1 and ip2. The third machine with ip3 is where the admin server is started.
              I have configured the cluster having ip1 and ip2 servers, thru the admin console.
              So now my cluster consists of ip1 and ip2 listening at port 7005. Admin server
              is
              started at port 7001. I have added the HttpClusterServlet related details in the
              web.xml under %WL_HOME%\config\examples\examplesWebApp\Web-inf.
              I started the three instances of WebLogic on the respective machines.
              Then in the Web Browser i give the url:
              http://ip1:7005/SimpleSession.jsp
              this keeps saying 'Web site found Waiting for reply' but there is no reply only
              an operation timed out finally. ip1 is one of my clustered servers.
              My HttpClusterServlet setting is on ip3, but if i use the url : http://ip3:7001/SimpleSession.jsp,
              it gives Error 404..Bad Request.
              How am i supposed to invoke the servlet?? i mean using which server, the admin
              or the clustered???
              Please do let me know what i shud do. Can you please give me a detailed scenario
              or settings i need to make?
              Thanks in advance for the help.
              regards,
              deepali
              ps: i am using WebLogic 6.1(sp2) on NT WorkStations.
              Raj Alagumalai <[email protected]> wrote:
              >Deepali,
              >
              >You can setup another instance of WebLogic to act as the proxy server
              >
              >and test the cluster.
              >
              >Please refer to the following document for more information on this
              >http://e-docs.bea.com/wls/docs61////adminguide/http_proxy_cluster.html
              >
              >Thanks
              >
              >Raj Alagumalai
              >Developer Relations Engineer
              >BEA Support
              >
              >Deepali wrote:
              >
              >> Hi,
              >>
              >> I have configured the WebLogic Server for Servlet Clustering. But how
              >do I know that the servlet configuration is working?
              >> I am using WebLogic 6.1 (sp2), I am using two different machines (NT
              >WorkStations) as members of a cluster. I invoke the jsp (or any servlet)
              >with the following url:
              >> http://ipofoneoftheclusteredservers:7005/examplesWebApp/HelloWorld.jsp
              >> or with
              >> http://ipoftheotherclusteredserver:7005/examplesWebApp/HelloWorld.jsp
              >>
              >> both of these give results, but how do i test this setup for clustering??
              >> let me know !
              >>
              >> -dee
              >>
              >
              

  • Pros/Cons of separating servlet/EJB clusters

              What and the pros and cons of establishing a cluster for the servlet layer and
              a separate cluster for the EJB layer?
              The rational behind this decision would be to take advantage of a shared infrastructure
              where multiple EJB components could be deployed in a cluster where they are accessed
              from multiple servlet/clusters.
              The obvious con is the fact that all calls between the servlet layer and the EJB
              layer will be remote calls however, there should be a greater level of availability
              and scalability.
              What are the other issues behind this deployment strategy?
              

    I don't recall any other problems with this topology other than the one
              that you already mentioned. Infact i have seen several customer using
              this topology. i.e. having WebTier Cluste and EJB tier cluster.
              Kumar
              JD wrote:
              > What and the pros and cons of establishing a cluster for the servlet layer and
              > a separate cluster for the EJB layer?
              >
              > The rational behind this decision would be to take advantage of a shared infrastructure
              > where multiple EJB components could be deployed in a cluster where they are accessed
              > from multiple servlet/clusters.
              >
              > The obvious con is the fact that all calls between the servlet layer and the EJB
              > layer will be remote calls however, there should be a greater level of availability
              > and scalability.
              >
              > What are the other issues behind this deployment strategy?
              >
              

  • Servlet error in clustering env.

              Guess this is something to do with the servlet clustering configuration. WLS(5.1, sp6) clustering run on Solaris 2.6 with jdk1.2.
              Do any one have any idea what could be the problems?
              =========================================================
              Mon Dec 11 15:58:19 EST 2000:<I> <ServletContext-General> Generated java file: /home/weblogic/5.1/ourserver/cl
              assfiles/jsp_servlet/_html/_libraries/_vieworg.java
              Mon Dec 11 15:58:20 EST 2000:<E> <ServletContextManager> Servlet request terminiated with Error
              weblogic.cluster.replication.BadStatusException: update found 4586531668847271614 but it is not the secondary
              at java.lang.Throwable.fillInStackTrace(Native Method)
              at java.lang.Throwable.fillInStackTrace(Compiled Code)
              at weblogic.rmi.extensions.AbstractRequest.sendReceive(Compiled Code)
              at weblogic.cluster.replication.ReplicationManager_WLStub.update(Compiled Code)
              at weblogic.cluster.replication.ReplicationManager.updateSecondary(Compiled Code)
              at weblogic.servlet.internal.session.ReplicatedSession.sync(Compiled Code)
              at weblogic.servlet.internal.session.ReplicatedSessionContext.sync(Compiled Code)
              at weblogic.servlet.internal.ServletRequestImpl.syncSession(Compiled Code)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              at weblogic.servlet.internal.ServletContextManager.invokeServlet(Compiled Code)
              at weblogic.socket.MuxableSocketHTTP.invokeServlet(Compiled Code)
              at weblogic.socket.MuxableSocketHTTP.execute(Compiled Code)
              at weblogic.kernel.ExecuteThread.run(Compiled Code)
              --------------- nested within: ------------------
              weblogic.utils.NestedError: Tried to update secondary, but it thought it was the primary - with nested exceptio
              n:
              [weblogic.cluster.replication.BadStatusException: update found 4586531668847271614 but it is not the secondary]
              at java.lang.Throwable.fillInStackTrace(Native Method)
              at java.lang.Throwable.fillInStackTrace(Compiled Code)
              at java.lang.Throwable.<init>(Compiled Code)
              at java.lang.Error.<init>(Error.java:50)
              at weblogic.utils.NestedError.<init>(NestedError.java:23)
              at weblogic.servlet.internal.session.ReplicatedSession.sync(Compiled Code)
              at weblogic.servlet.internal.session.ReplicatedSessionContext.sync(Compiled Code)
              at weblogic.servlet.internal.ServletRequestImpl.syncSession(Compiled Code)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              at weblogic.servlet.internal.ServletContextManager.invokeServlet(Compiled Code)
              at weblogic.socket.MuxableSocketHTTP.invokeServlet(Compiled Code)
              at weblogic.socket.MuxableSocketHTTP.execute(Compiled Code)
              at weblogic.kernel.ExecuteThread.run(Compiled Code)
              

    You should search in your log for message "Timed out server". If you see this,
              it means that your cluster is not healthy.
              Long gc is attributed to memory. If you don't have enough heap memory vm will
              take more time to do gc and during this time the server won't be able to do any
              work. If two servers are running gc's at different times, what you have is two
              servers in a cluster timing out each other at different times causing this
              problem to aggrevate.
              One way to solve the problem is by tuning the server so that you won't run into
              this problem.
              We designed the system differently to overcome this problem based on our
              experience with 4.5 and 5.1. It is not an easy thing to back port this change
              into a service pack.
              Yes, the fix to minimize the problem did go in 5.1
              Let me know if anything is unclear.
              Thanks
              - Prasad
              Joel Nylund wrote:
              > I have been working with weblogic support on this one for a while, they say
              > its fixed in 6.0 (which sucks for those of us still 4.5.1). They said it
              > happens less in sp13 for 4.51, im not sure if there is a similar patch for
              > 5.x. I would contact support. They say the reasons for this are one of :
              >
              > 1.) unreliable network
              > 2.) long gc loop or not enough memory (never understood this one)
              >
              > -Joel
              >
              > "Key Zhang" <[email protected]> wrote in message
              > news:[email protected]...
              > >
              > > Guess this is something to do with the servlet clustering configuration.
              > WLS(5.1, sp6) clustering run on Solaris 2.6 with jdk1.2.
              > >
              > >
              > > Do any one have any idea what could be the problems?
              > >
              > > =========================================================
              > > Mon Dec 11 15:58:19 EST 2000:<I> <ServletContext-General> Generated java
              > file: /home/weblogic/5.1/ourserver/cl
              > > assfiles/jsp_servlet/_html/_libraries/_vieworg.java
              > > Mon Dec 11 15:58:20 EST 2000:<E> <ServletContextManager> Servlet request
              > terminiated with Error
              > > weblogic.cluster.replication.BadStatusException: update found
              > 4586531668847271614 but it is not the secondary
              > > at java.lang.Throwable.fillInStackTrace(Native Method)
              > > at java.lang.Throwable.fillInStackTrace(Compiled Code)
              > > at weblogic.rmi.extensions.AbstractRequest.sendReceive(Compiled
              > Code)
              > > at
              > weblogic.cluster.replication.ReplicationManager_WLStub.update(Compiled Code)
              > > at
              > weblogic.cluster.replication.ReplicationManager.updateSecondary(Compiled
              > Code)
              > > at
              > weblogic.servlet.internal.session.ReplicatedSession.sync(Compiled Code)
              > > at
              > weblogic.servlet.internal.session.ReplicatedSessionContext.sync(Compiled
              > Code)
              > > at
              > weblogic.servlet.internal.ServletRequestImpl.syncSession(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextManager.invokeServlet(Compiled Code)
              > > at weblogic.socket.MuxableSocketHTTP.invokeServlet(Compiled Code)
              > > at weblogic.socket.MuxableSocketHTTP.execute(Compiled Code)
              > > at weblogic.kernel.ExecuteThread.run(Compiled Code)
              > > --------------- nested within: ------------------
              > > weblogic.utils.NestedError: Tried to update secondary, but it thought it
              > was the primary - with nested exceptio
              > > n:
              > > [weblogic.cluster.replication.BadStatusException: update found
              > 4586531668847271614 but it is not the secondary]
              > > at java.lang.Throwable.fillInStackTrace(Native Method)
              > > at java.lang.Throwable.fillInStackTrace(Compiled Code)
              > > at java.lang.Throwable.<init>(Compiled Code)
              > > at java.lang.Error.<init>(Error.java:50)
              > > at weblogic.utils.NestedError.<init>(NestedError.java:23)
              > > at
              > weblogic.servlet.internal.session.ReplicatedSession.sync(Compiled Code)
              > > at
              > weblogic.servlet.internal.session.ReplicatedSessionContext.sync(Compiled
              > Code)
              > > at
              > weblogic.servlet.internal.ServletRequestImpl.syncSession(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextImpl.invokeServlet(Compiled Code)
              > > at
              > weblogic.servlet.internal.ServletContextManager.invokeServlet(Compiled Code)
              > > at weblogic.socket.MuxableSocketHTTP.invokeServlet(Compiled Code)
              > > at weblogic.socket.MuxableSocketHTTP.execute(Compiled Code)
              > > at weblogic.kernel.ExecuteThread.run(Compiled Code)
              > >
              

  • Quick 5.1 JSP clustering question...

    Does JSP/servlet clustering (WL 5.1) absolutely require a proxy sitting in
              front of the clustered servers?
              Brian Dainton
              Pervado Systems, Inc.
              www.pervado.com
              

    Yes.
              Brian Dainton wrote:
              > Does JSP/servlet clustering (WL 5.1) absolutely require a proxy sitting in
              > front of the clustered servers?
              >
              > Brian Dainton
              > Pervado Systems, Inc.
              > www.pervado.com
              

  • Load balancing with JSP

    Anyone and everyone,
    When configuring load balancing with Weblogic clusters, does load
    balancing take effect for all services or just EJB and RMI? Or another
    way of saying the same thing, can I setup weighted load balancing for
    the JSP engines across 2 weblogic servers.
    Thanks in advance,
    Mike

    The load-balancing documentation you read describing the different algorithms only applies to RMI stubs (e.g., EJB clients). Please see http://www.weblogic.com/docs51/cluster/concepts.html#1026091 for a description of how load-balancing/clustering works with servlets/JSPs.
    The short answer is that in using servlet clustering, most people want/need/use in-memory replication for HttpSession objects. In WLS 5.1 (and before), in-memory replication requires one or more proxy servers be set-up in front of the cluster. Typically, most people use something like BigIP to load-balance
    across the proxy servers and let the weblogic plug-in for the proxy server handle the routing to the cluster. The plug-in uses round-robin until an HttpSession is established for a user, then it always tries to route to the server where the user's session is located.
    Hope this helps,
    Robert
    Brian Lin wrote:
    All,
    I have a quesiton here regarding load balancing with DNS round robin. As of Chapter Adminstration of Clustering Weblogic server, Weblogic can be configured to balance by weight. How about Weblogic handle weight based balancing after DNS round robin ip response? or just can choose one way instead of both?
    What's the big difference between choosing BigIP and software balancing (WL)?
    Brian
    "Wei Guan" <[email protected]> wrote:
    I don't think you can configure this load balancing in weblogic in current
    release. However, if you have Big-IP or LocalDireoctr, you can set up
    weighted load-balancing there. Otherwise, weblogic proxy will use DNS round
    robin to do the load-balancing between JSP engins.
    My 2 cents.
    Cheers - Wei
    Michael Yakimisky <[email protected]> wrote in message
    news:[email protected]...
    Anyone and everyone,
    When configuring load balancing with Weblogic clusters, does load
    balancing take effect for all services or just EJB and RMI? Or another
    way of saying the same thing, can I setup weighted load balancing for
    the JSP engines across 2 weblogic servers.
    Thanks in advance,
    Mike

  • Using Toplink with Servlets in a Clustered application server

    I am having some problems with Toplink.
    Basically, I have a collection of HttpServlets that manipulate a domain object and its various collections of objects. The general technique is to place the domain object in the HttpSession, and have each Servlet modify this object by retrieving it, modifying it, and storing it when necessary. The problem is that since this application is running in a clustered environment, the object in the session may or may not be the same object returned from Toplink. It may be a serialized clone of the object from another server on the cluster.
    This has caused several problems. First, if I am using indirction for the collections, when the domain object is deserializaed, it throws an exception when it tries to instantiate the indirection. Next, when trying to store the object, it is not registered with a unit of work, and I am not sure how to properly account for this. Third, there is a many to many relationship. The user may pick one such object, and add it to the domain object being manipulated. This seems to cause problems when the object is read from Toplink, and added to the domain object that is a serialized clone.
    Anyway, my question is, what is the general pattern for handling an object being manipulated on a HttpSession in a clustered environment, where this object(s) may or may not be the actual objects returned from Toplink? My goal is to have a factory return one DatabaseSession per cluster server, and be able to load, store, and manipulate these objects in the HttpSession.
    Here is an attempt at code:
    import java.io.*;
    import java.util.*;
    import oracle.toplink.expressions.*;
    import oracle.toplink.sessions.*;
    public class DataAccess
    private static Project project = new MyToplinkProject();
    private static DatabaseSession session;
    private UnitOfWork unit;
    public DataAccess()
    unit = getDatabaseSession().acquireUnitOfWork();
    public ArrayList getAllCustomers()
    Vector v = (Vector) session.readAllObjects(Customer.class);
    return new ArrayList(v);
    public Customer getCustomerForUpdate(Customer c)
    Customer custCopy = (Customer) unit.readObject(c);
    return (Customer) unit.registerObject(c);
    public Form getCustomer(String id)
    ExpressionBuilder builder = new ExpressionBuilder();
    Expression exp = builder.get("id").equal(id);
    return (Customer) session.readObject(Customer.class, exp);
    public void saveCustomer(Customer cust)
    unit.deepMergeClone(cust);
    unit.commitAndResume();
    private synchronized DatabaseSession getDatabaseSession()
    if (session == null)
    session = project.createDatabaseSession();
    session.login();
    session.setLog(new PrintWriter(System.out));
    session.logMessages();
    return session;
    public void destruct()
    release();
    public void release()
    unit.release();
    session.release();
    Anyway, from this code I hope you can see what I am trying to do. The basic idea is that a Customer object provided for store and update may or may not be a serialized copy. Also, the object returned from a read may be serialized before the indirction is attempted.
    Thanks for any help,
    Jason Wilson

    Hi Jason
    A single static DatabaseSession and a single static UnitOfWork is not the recommended way of working with TopLink from a servlet. Our recommendation is that you create a single ServerSession object and that every time a servlet needs to interact with a TopLink Session, the servlet first acquires a ClientSession from this ServerSession object and possibly acquires UnitOfWork from the ClientSession. A UnitOfWork is not intended to be shared by servlets, or by different clients.
    Basically, what you're attempting to do with the DatabaseSession is something we would recommend that you do instead with a ServerSession/ClientSessions combination.
    As for working with persistent objects that you store in an HttpSession, I will try to give you some relevant background. First off, the UnitOfWork is intended to be used to manage the changes to a set of objects in a SINGLE TRANSACTION. It is always much easier to manage if these transactions are short-lived (ie if there is one transaction per ServletRequest.
    However, the fact that you are talking about storing objects in the HttpSession makes me think that you are also considering long-running transactions that are may be spread out over several ServletRequests. You should definately consider this decision very carefully. If you want to continually edit an object that is stored in the HttpSession, then we need to consider how to manage when the object's changes should be committed to the database and how to manage concurrency when two users have the same object in their respective HttpSession objects.
    One idea is not to store the actual object in the HttpSession but instead to store the "id" of the object (something that you can use to find the correct object when the same user makes another request). So servlets always:
    -acquireClientSession
    -find the object that they are working with (based on information in the HttpSession)
    -if the object is to be edited then a UnitOfWork provides clones of the object (this isolates you from changes that some other user makes to the same object)
    -at the end, commit the changes to the object.
    When the user makes another request, the object they read will have their changes. So, functionally, this is the same as storing the actual object in the HttpSession, except TopLink can provide proper ACID behavior for any updates that you decide to make. And don't worry about the added "expense" of having to query at the beginning of each servlet request; if you are storing the "id" of the object in your HttpSession, then you a simple cache hit is all that is required to get back the correct object. You don't have to go the database at all.
    JIM

  • EJB and Servlets on different clusters

              Say I set up two clusters, one for servlets and one for EJBs.
              To lookup to EJBs, the servlets must look up an initial context and provide a URL.
              Should the URL be hardcoded in the servlet to the EJB cluster name, or is there a way
              to specify this URL at a higher level?
              Can you specify something like this in the properties file?
              What's the best way to do this?
              Please advise,
              Dave
              

    David,
              How about specifying the EJB cluster URL in the servlets init argument in the
              weblogic.properties ??
              Sam
              David Mrozek wrote:
              > Say I set up two clusters, one for servlets and one for EJBs.
              > To lookup to EJBs, the servlets must look up an initial context and provide a URL.
              > Should the URL be hardcoded in the servlet to the EJB cluster name, or is there a way
              > to specify this URL at a higher level?
              > Can you specify something like this in the properties file?
              > What's the best way to do this?
              > Please advise,
              > Dave
              

  • EJB & Servlet deployment in Clustered Env.

              Hi,
              I have made a cluster of 3 weblogic servers. I would like to send a request to one
              server (e.g. http://myserver1:7001/TestServlet). The servlet utilizes an EJB which
              is not located and not deployed on myserver1 , but on other 2 servers in the cluster.
              The algorithm is round-robin. It gives me a lot of errors (Impl... classes not found
              etc etc).
              Do I have to deploy everything on all the servers?
              If I do that, the request is not routed to other servers. Since the servlet finds
              the EJB locally, it never goes to the other servers, regardless of the algorithm.
              I have set up the "home-is-clusterable" and all other relevant properties for EJB
              deployment.
              Any ideas??
              Sharad
              

    If the ejb is deployed on the server that is looking for the ejb, then it
              won't go network to use the ejb. That is a "big" WL optimization, and helps
              quite a bit for most apps.
              If you want to segregate the ejb and web functionality, you should probably
              consider running two distinct clusters (in 5.1 parlance).
              I suggest putting web and ejb together though and clustering that. Latency
              is lower. Scalability is not particularly affected. Configuration is much
              simpler.
              Peace,
              Cameron Purdy
              Tangosol, Inc.
              http://www.tangosol.com
              +1.617.623.5782
              WebLogic Consulting Available
              "Sharad Joshi" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Hi,
              >
              > I have made a cluster of 3 weblogic servers. I would like to send a
              request to one
              > server (e.g. http://myserver1:7001/TestServlet). The servlet utilizes an
              EJB which
              > is not located and not deployed on myserver1 , but on other 2 servers in
              the cluster.
              > The algorithm is round-robin. It gives me a lot of errors (Impl... classes
              not found
              > etc etc).
              >
              > Do I have to deploy everything on all the servers?
              > If I do that, the request is not routed to other servers. Since the
              servlet finds
              > the EJB locally, it never goes to the other servers, regardless of the
              algorithm.
              > I have set up the "home-is-clusterable" and all other relevant properties
              for EJB
              > deployment.
              >
              > Any ideas??
              >
              > Sharad
              

  • Servlets, EJB in clustering!

    Hello,
    Im new to the clustering mechanism and would like to know:
    1. Can servlets which are associated with EJBs can also be clustered?
    2. How about an RMI Server running in association with an app server? Can that too be clustered?
    - ananth

    clustering capability is not defined in the specification, each vendor decides what to support. However, for the most part J2EE servers support clustering of web and ejb components as well as JMS and JNDI. I don't know of any off hand that support clustering of RMI (beyond RMI over IIOP for EJB's).
    Chuck

  • Clustering behavior for servlets/JHTML?

    I have two questions about the clustering behavior of servlets and
              JHTML:
              1. Is it a safe assumption that JHTML servlets behave identically to
              regular, developer-written servlets?
              2. How does the clustering mechanism work? Say I have a user who logs in
              to my site (which is a 4-server, weblogic cluster). Does that user
              session always get directed back to the same server (say in this case,
              server #1)? Or does the user session get directed to the server with the
              lowest load at the time of the request?
              Thanks.
              Chien Huey
              [email protected]
              

    Hi DH84,
    Please offer us more information about your current cluster configuration, such as the event cluster occur, the server edition,
     please disable RSS, TCP Chimney on both cluster nodes RSS, NetDMA to narrow down the issue first.
    If you are using 2008R2 cluster please confirm you have installed the following hotfix,
    Slow failover operation if no router exists between the cluster and an application server
    http://support.microsoft.com/kb/2582281
    A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working
    http://support.microsoft.com/kb/2550886
    I’m glad to be of help to you!
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

  • Weblogic 7.0 servlets deployment and clustering

              I am unable to deploy servlet application in WL 7.0 cluster configuration. I am
              using Iplanet NES 4.0 as my web server. I have deployed the weblogic proxy successfully
              in iplanet.
              The servlet application has class files in exploded form and are present under
              bin/applications/DefaultWebApp/WEB-INF/classes folder
              web.xml also exists in the above folder.
              I receive the following exception.
              <Apr 23, 2003 2:26:44 PM EDT> <Error> <socket> <000405> <Uncaught Throwable in
              processSockets
              java.lang.NullPointerException
              java.lang.NullPointerException
              at weblogic.servlet.internal.ServletResponseImpl.writeHeaders(ServletResponseImpl.java:968)
              at weblogic.servlet.internal.ServletOutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:239)
              at weblogic.servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121)
              at weblogic.servlet.internal.ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:481)
              at weblogic.servlet.internal.ChunkOutput.commit(ChunkOutput.java:259)
              at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:91)
              at weblogic.servlet.internal.ChunkWriter.write(ChunkWriter.java:37)
              at java.io.Writer.write(Writer.java:148)
              at java.io.PrintWriter.write(PrintWriter.java:208)
              Please help.
              

    This might be a known bug, please contact support and reference CR100572 to
              see if it is also a bug in WLS7.0
              sree
              "Manju" <[email protected]> wrote in message
              news:[email protected]...
              >
              > I am unable to deploy servlet application in WL 7.0 cluster configuration.
              I am
              > using Iplanet NES 4.0 as my web server. I have deployed the weblogic proxy
              successfully
              > in iplanet.
              > The servlet application has class files in exploded form and are present
              under
              > bin/applications/DefaultWebApp/WEB-INF/classes folder
              > web.xml also exists in the above folder.
              > I receive the following exception.
              > <Apr 23, 2003 2:26:44 PM EDT> <Error> <socket> <000405> <Uncaught
              Throwable in
              > processSockets
              > java.lang.NullPointerException
              > java.lang.NullPointerException
              > at
              weblogic.servlet.internal.ServletResponseImpl.writeHeaders(ServletResponseIm
              pl.java:968)
              > at
              weblogic.servlet.internal.ServletOutputStreamImpl.sendHeaders(ServletOutputS
              treamImpl.java:239)
              > at
              weblogic.servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamI
              mpl.java:121)
              > at
              weblogic.servlet.internal.ServletOutputStreamImpl.commit(ServletOutputStream
              Impl.java:481)
              > at
              weblogic.servlet.internal.ChunkOutput.commit(ChunkOutput.java:259)
              > at
              weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:9
              1)
              > at
              weblogic.servlet.internal.ChunkWriter.write(ChunkWriter.java:37)
              > at java.io.Writer.write(Writer.java:148)
              > at java.io.PrintWriter.write(PrintWriter.java:208)
              >
              >
              > Please help.
              >
              

  • Clustering and Application/Servlet Singletons...Replicated?

    Are static servlet and instance attributes replicated to servlet instances
              in cluster?
              We have seen some behavior which suggest no?
              Assuming all instance and static variables are serializable or atomic types,
              are they replicated?
              If not, how is application/servlet level state replicated? servletcontext?
              -phil ([email protected])
              [Phillip A. Lindsay.vcf]
              

    "Phillip A. Lindsay" wrote:
              > Are static servlet and instance attributes replicated to servlet instances
              > in cluster?
              Each node will have its own class/classloader tuple and therefore its own set
              of static and instance attributes. The singleton effect can be achieved by
              binding
              an object into a namespace at a well-known point. It can be argued that a
              singleton
              should be replicated but then it wouldn't be a "single" singleton.
              Cheers
              Alex
              mailto:[email protected] // Consulting services available
              

  • Working with EAR file & (Servlet/JSP) Clustering - Please Help

              Hi,
              In my project we pack our application using EAR file. We read BEA's article, which
              discussed the class loaders hierarchy and it looks like this problem should not occur:
              When the garbage collection is being invoked - it somehow fails to resolve the class
              weblogic.jndi.WLInitialContextFactory.
              We have encountered the following error (stack trace):
              Message: severity="ERROR" sessionId="9IUUN4xoQf1wOkfEN8m62SFjEpNC1e4lLHSzyc2s01GPk5Up25cJ!-1680906364!182460375!7559!7002!1728341859!182464192!7559!7002!1023972500766"
              date="Jun 13, 2002" time="3:49:05 PM" threadId="Finalizer"
              Description:
              Throw:     amdocs.jspInfra.exceptions.FailedToRemoveEjbException: [an error occurred
              while trying to remove an ejb.]
              null- caused by: amdocs.jspInfra.exceptions.InitialContextCreationFailureException:
              [an error occurred while trying to create a new initial context.]
              null- caused by: javax.naming.NoInitialContextException: Cannot instantiate class:
              weblogic.jndi.WLInitialContextFactory [Root exception is java.lang.ClassNotFoundException:
              weblogic/jndi/WLInitialContextFactory]
              amdocs.jspInfra.exceptions.InitialContextCreationFailureException: [an error occurred
              while trying to create a new initial context.]
              null- caused by: javax.naming.NoInitialContextException: Cannot instantiate class:
              weblogic.jndi.WLInitialContextFactory [Root exception is java.lang.ClassNotFoundException:
              weblogic/jndi/WLInitialContextFactory]
              javax.naming.NoInitialContextException: Cannot instantiate class: weblogic.jndi.WLInitialContextFactory.
              Root exception is java.lang.ClassNotFoundException: weblogic/jndi/WLInitialContextFactory
                   at java.lang.Class.forName0(Native Method)
                   at java.lang.Class.forName(Class.java:195)
                   at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:45)
                   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:652)
                   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246)
                   at javax.naming.InitialContext.init(InitialContext.java:222)
                   at javax.naming.InitialContext.<init>(InitialContext.java:198)
                   at amdocs.jspInfra.userManagement.RequestContext._createContext(RequestContext.java:550)
                   at amdocs.jspInfra.userManagement.RequestContext.createContext(RequestContext.java:391)
                   at amdocs.jspInfra.userManagement.RequestContext.createContext(RequestContext.java:415)
                   at amdocs.jspInfra.beans.GenericJspBean._removeConversation(GenericJspBean.java:466)
                   at amdocs.jspInfra.beans.GenericJspBean._cleanUp_(GenericJspBean.java:413)
                   at amdocs.jspInfra.beans.GenericJspBean.cleanUp_(GenericJspBean.java:117)
                   at amdocs.jspInfra.beans.GenericJspBean.finalize(GenericJspBean.java:593)
                   at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
                   at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:86)
                   at java.lang.ref.Finalizer.access$100(Finalizer.java:17)
                   at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:163)
              

    The context classloader needs to be set so that the thread can load the
              Weblogic context factory class inside the finalizer thread.
              Simply save the context classloader when running inside the ejb code and set
              that inside finalize method so that the class can get loaded correctly.
              1) keep a member variable
              ClassLoader myccl;
              2) Instantiate it in the regular application thread as
              myccl = Thread.currentThread().getContextClassLoader();
              3) In the finalize() method keep this as the first line.
              Thread.currentThread().setContextClassLoader(myccl);
              -Sabha
              "Yossi Cohen" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Hi,
              >
              > In my project we pack our application using EAR file. We read BEA's
              article, which
              > discussed the class loaders hierarchy and it looks like this problem
              should not occur:
              > When the garbage collection is being invoked - it somehow fails to resolve
              the class
              > weblogic.jndi.WLInitialContextFactory.
              > We have encountered the following error (stack trace):
              >
              > Message: severity="ERROR"
              sessionId="9IUUN4xoQf1wOkfEN8m62SFjEpNC1e4lLHSzyc2s01GPk5Up25cJ!-1680906364!
              182460375!7559!7002!1728341859!182464192!7559!7002!1023972500766"
              > date="Jun 13, 2002" time="3:49:05 PM" threadId="Finalizer"
              > Description:
              > Throw: amdocs.jspInfra.exceptions.FailedToRemoveEjbException: [an error
              occurred
              > while trying to remove an ejb.]
              > null- caused by:
              amdocs.jspInfra.exceptions.InitialContextCreationFailureException:
              > [an error occurred while trying to create a new initial context.]
              > null- caused by: javax.naming.NoInitialContextException: Cannot
              instantiate class:
              > weblogic.jndi.WLInitialContextFactory [Root exception is
              java.lang.ClassNotFoundException:
              > weblogic/jndi/WLInitialContextFactory]
              > amdocs.jspInfra.exceptions.InitialContextCreationFailureException: [an
              error occurred
              > while trying to create a new initial context.]
              > null- caused by: javax.naming.NoInitialContextException: Cannot
              instantiate class:
              > weblogic.jndi.WLInitialContextFactory [Root exception is
              java.lang.ClassNotFoundException:
              > weblogic/jndi/WLInitialContextFactory]
              > javax.naming.NoInitialContextException: Cannot instantiate class:
              weblogic.jndi.WLInitialContextFactory.
              > Root exception is java.lang.ClassNotFoundException:
              weblogic/jndi/WLInitialContextFactory
              > at java.lang.Class.forName0(Native Method)
              > at java.lang.Class.forName(Class.java:195)
              > at
              com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:45)
              > at
              javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:652)
              > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246)
              > at javax.naming.InitialContext.init(InitialContext.java:222)
              > at javax.naming.InitialContext.<init>(InitialContext.java:198)
              > at
              amdocs.jspInfra.userManagement.RequestContext._createContext(RequestContext.
              java:550)
              > at
              amdocs.jspInfra.userManagement.RequestContext.createContext(RequestContext.j
              ava:391)
              > at
              amdocs.jspInfra.userManagement.RequestContext.createContext(RequestContext.j
              ava:415)
              > at
              amdocs.jspInfra.beans.GenericJspBean._removeConversation(GenericJspBean.java
              :466)
              > at amdocs.jspInfra.beans.GenericJspBean._cleanUp_(GenericJspBean.java:413)
              > at amdocs.jspInfra.beans.GenericJspBean.cleanUp_(GenericJspBean.java:117)
              > at amdocs.jspInfra.beans.GenericJspBean.finalize(GenericJspBean.java:593)
              > at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
              > at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:86)
              > at java.lang.ref.Finalizer.access$100(Finalizer.java:17)
              > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:163)
              >
              

  • Error 404 -- Not Found, when a Servlet is invoked from browser

    Obviously, I have not been able to configure my WebLogic Server 5.1.0 to run
              even the simplest servlet.
              I painstakenly went through all the steps that are listed in the WebLogic
              Server 5.1.0 documentation on the Web to enable servlets, but obviously, I
              have missed a step somewhere.
              I have modified the weblogic.properties file as per all the instrustions,
              but the server simply won't recognize any servlets, not even the SqlServlet
              that came with the server as an example.
              It would require more than 1 exchange of posts to resolve it for me, and I
              am wondering if one of you is willing to work with me on this until I have
              managed to configure the server to make a servlet work on it.
              The server does function as a Web server as I can run the index.html
              document by entering the URL: http://localhost:7001/index.html
              I am pasting the contents of weblogic.properties file below to get the
              person who is willing to help me started.
              The machine I have is a Pentium III with Windows 2000 Professional on it.
              It's a home machine and the WebLogic server is the freely downloadable
              version. I am using it to prepare for a potential contract work.
              I have managed to modify setEnv.cmd file and have managed to compile the
              SqlServlet.java, which is an example servlet. Neither this particular
              servlet nor a HelloWorld type of very basic servlet I have written are
              recognized by the server.
              As you can see from my weblogic.properties file (pasted at the end of this
              post), the SqlServlet has been registered. I have also uncommented the lines
              to allow for the following type of URL:
              http://localhost:7001/servlet/myServlet
              Thanks!
              Anjum Jaleel
              CONTENTS OF MY weblogic.properties file
              # THE WEBLOGIC PROPERTIES FILE
              # This file, which conforms to the java.util.Properties file
              # definition, configures your WebLogic products. You cannot run
              # WebLogic Server without setting required configuration properties in this
              # file. Required properties are marked and appear first in the file.
              # Details on each entry and important information about configuration
              # and security are documented on our website. Please go to:
              # http://www.weblogic.com/docs51/admindocs/properties.html
              # for full instructions on how to edit this file.
              # You do not need to include properties in this file unless you want to
              # change the default, embedded property. Some properties on the
              # AdminProps page are not listed here because the default property
              # is being used. You can change the default by adding the property and
              # its value to this file.
              # You cannot set weblogic.system.home in this file, since the WebLogic
              Server
              # must know where home is in order to retrieve this file. You can
              # change WebLogic home on the command line when you start the
              # WebLogic Server.
              # CLUSTER USERS: Note that the (shared) per-cluster properties file should
              # contain most all of the properties in this file. The only properties
              # that potentially belong in a per-server properties file for a server
              # running in a cluster are the registration (startup class) of pinned
              # RMI objects, and a few tuning properties that may be different for
              # servers in the cluster, depending upon hardware and memory. If you use
              # a per-server properties file, please REMOVE all properties except those
              # that are specifically required in the per-server properties file. You
              # can find specific notes on clusters by searching through this file for
              # "CLUSTER USERS".
              # The way this file is organized:
              # Core properties (includes REQUIRED and RECOMMENDED)
              # Core system properties
              # Core security-related properties
              # Core security-related properties for SSL
              # Core HTTPD administrative properties
              # Optional properties
              # Administrator properties
              # System properties
              # System startup files
              # System shutdown files
              # Security-related properties for Workspaces
              # Jolt for WebLogic properties
              # WebLogic Enterprise Connectivity properties
              # WebLogic File properties
              # WebLogic JMS demo properties
              # WebLogic RMI demo properties
              # WebLogic EJB demo properties
              # WebLogic XML demo properties
              # WebLogic ZAC demo properties
              # HTTPD administrative properties
              # WebLogic JDBC driver properties
              # WebLogic JDBC connection pool management
              # WebLogic demo connection pool
              # WebLogic HTTP Servlet properties
              # Proxy servlet registration
              # Classpath servlet registration
              # File servlet registration
              # ServerSideInclude servlet registration
              # PageCompileServlet (used by JHTML)
              # JSPServlet (used by JSP)
              # ServletServlet registration
              # Servlet reload properties
              # Servlet ACLs
              # WebLogic JSP properties
              # WebLogic JHTML properties
              # WebLogic RMI over IIOP properties
              # User-written and demo servlet registrations
              # CORE PROPERTIES
              # You should set these before you start the WebLogic Server the first time.
              # If you need more instructions on individual properties in this
              # section, check the same section in the Optional Properties, where
              # we've left the long explanations. Or, better yet, go to our
              # website and read all about properties, at:
              # http://www.weblogic.com/docs51/admindocs/properties.html
              # CORE SYSTEM PROPERTIES
              # TCP/IP port number at which the WebLogic Server listens for connections
              weblogic.system.listenPort=7001
              # CORE SECURITY-RELATED PROPERTIES
              # Read important information about security at:
              # http://www.weblogic.com/docs51/admindocs/properties.html
              # REQUIRED: The system password MUST be set in order to start the
              # WebLogic Server. This password is case-sensitive, at least 8 characters.
              # The username for the privileged user is ALWAYS "system".
              # This username and password also includes httpd access (see
              # HTTPD properties below).
              weblogic.password.system=lovkako1
              # RECOMMEND Set to 'everyone' if HTTPD is enabled
              weblogic.allow.execute.weblogic.servlet=everyone
              # Set individual ACLs to restrict access to HTTP-related resources,
              # such as the Administration servlets.
              # To make your own servlets generally available, follow this
              # pattern (provide a weblogic.allow.execute) for your packages and
              # set ACLs as appropriate.
              # CORE SECURITY-RELATED PROPERTIES FOR SSL
              # Read important information about SSL at:
              # http://www.weblogic.com/docs51/classdocs/API_secure.html
              # Enable SSL
              # (default if property not defined is false)
              weblogic.security.ssl.enable=true
              # SSL listen port
              weblogic.system.SSLListenPort=7002
              # Servlets for SSL
              # Authentication servlet for creating tokens for applets
              weblogic.httpd.register.authenticated=weblogic.t3.srvr.ClientAuthenticationS
              ervlet
              # Limits number of unclaimed stored tokens
              weblogic.security.certificateCacheSize=3
              # Capture CA root of client servlet
              weblogic.httpd.register.AdminCaptureRootCA=admin.AdminCaptureRootCA
              # Certificates for SSL
              # Name of acceptable CA roots
              # For client authentication change value to a valid .pem file
              #weblogic.security.clientRootCA=SecureServerCA.pem
              # Server certificates for SSL
              weblogic.security.certificate.server=democert.pem
              weblogic.security.key.server=demokey.pem
              weblogic.security.certificate.authority=ca.pem
              # registration for certificate generator servlet
              weblogic.httpd.register.Certificate=utils.certificate
              weblogic.allow.execute.weblogic.servlet.Certificate=system
              # CORE HTTPD ADMINISTRATIVE PROPERTIES
              # True permits the HTTPD to run (default)
              # Uncomment this property to disable HTTPD
              weblogic.httpd.enable=true
              # If authentication is required, add username/password for each user
              # who will be included in an ACL, as in this commented-out example:
              #weblogic.password.peter=#8gjsL4*
              # OPTIONAL PROPERTIES
              # These properties affect the behavior of the WebLogic Server.
              # You only need to set these properties if you want
              # to change the default setting, which is the property shown.
              # ADMINISTRATOR PROPERTIES
              # Administrator properties are optional information properties,
              # particularly useful for clusters.
              #weblogic.administrator.location=3355 California Drive, West Hampshire, CA
              94104
              #weblogic.administrator.name=Joe Administrator
              #weblogic.administrator.phone=1 415 555 1234
              # SYSTEM PROPERTIES
              # System properties in this section are set to system defaults
              # Performance pack. The shared library must be accessible from your
              # PATH (NT) or from your shared library path (UNIX; the name of the
              # variable varies: LD_LIBRARY_PATH, SHLIB_PATH, etc.)
              weblogic.system.nativeIO.enable=true
              # Outputs logging information to the console as well as to the log file
              weblogic.system.enableConsole=true
              # Sets the directory or URL for the WebLogic Admin help pages
              # The help pages are shipped in the "docs/adminhelp" directory, in the
              # default document root in public_html
              weblogic.system.helpPageURL=g:/weblogic/myserver/public_html/docs51/adminhel
              p/
              # If you prefer to access the most recent help pages, you can do so online
              # by commenting out the previous property and uncommenting this one:
              #weblogic.system.helpPageURL=http://www.weblogic.com/docs51/adminhelp/
              # Properties for tuning the server's performance
              # Number of WebLogic Server execute threads.
              weblogic.system.executeThreadCount=15
              # Other optional system properties
              # Limits size of weblogic.log (in K) and versions old log
              weblogic.system.maxLogFileSize=1024
              # Adjust minimum length of password
              weblogic.system.minPasswordLen=8
              # UNIX only: If running on port 80 on UNIX, enable the setUID program
              #weblogic.system.enableSetUID=false
              # UNIX only: Unprivileged user to setUID to after starting up
              # WebLogic Server on port 80
              #weblogic.system.nonPrivUser=nobody
              # CLUSTER-SPECIFIC PROPERTIES
              # Cluster-specific properties in this section are set to system defaults.
              # CLUSTER USERS: Note that ALL Cluster-specific properties should be set
              # in the per-cluster properties file ONLY.
              # Time-to-live (number of hops) for the cluster's multicast messages
              # (default 1, range 1-255).
              #weblogic.cluster.multicastTTL=1
              # Sets the load-balancing algorithm to be used between
              # replicated services if none is specified. If not specified,
              # round-robin is used.
              #weblogic.cluster.defaultLoadAlgorithm=round-robin
              # SERVER-SPECIFIC CLUSTER PROPERTIES
              # Cluster-related properties in this section are set to system defaults.
              # CLUSTER USERS: Note that these server-specific cluster-related properties
              # should be set in the per-server properties file ONLY.
              # Sets the weight of the individual server for the weight-based
              load-balancing.
              # Range is 0 - 100.
              # Larger numbers increase the amount of traffic routed to this server.
              #weblogic.system.weight=100
              # SYSTEM STARTUP FILES - Examples
              # CLUSTER USERS: Note that ONLY startup registrations for pinned RMI
              # objects should be registered in the per-server properties file.
              # All other startup classes should be registered in the per-cluster
              # properties file.
              # For more info on writing and using startup file, see the
              # Developers Guide "Writing a WebLogic Client application," at
              # http://www.weblogic.com/docs51/classdocs/API_t3.html
              # Register a startup class by giving it a virtual name and
              # supplying its full pathname.
              #weblogic.system.startupClass.[virtual_name]=[full_pathname]
              # Add arguments for the startup class
              #weblogic.system.startupArgs.[virtual_name]={argname]=[argvalue]
              # This example shows the entry for examples/t3client/StartupQuery.java
              #weblogic.system.startupClass.doquery=examples.t3client.StartupQuery
              #weblogic.system.startupArgs.doquery=\
              # query=select * from emp,\
              # db=jdbc:weblogic:pool:demoPool
              # SYSTEM SHUTDOWN FILES - Examples
              # For more info on writing and using shutdown file, see the
              # Developers Guide "Writing a WebLogic Client application," at
              # http://www.weblogic.com/docs51/classdocs/API_t3.html
              # Register a shutdown class by giving it a virtual name and
              # supplying its full pathname.
              #weblogic.system.shutdownClass.[virtual_name]=[full_pathname]
              # Add arguments for the shutdown class
              #weblogic.system.shutdownArgs.[virtualName]={argname]=[argvalue]
              # This example shows the entry for examples/t3client/ShutdownTest.java
              #weblogic.system.shutdownClass.ShutdownTest=examples.t3client.ShutdownTest
              #weblogic.system.shutdownArgs.ShutdownTest=\
              # outfile=c:/temp/shutdown.log
              # SECURITY-RELATED PROPERTIES FOR WORKSPACES
              # For backward compatibility, the following entries disable Access
              # Control on Workspaces
              weblogic.allow.read.weblogic.workspace=everyone
              weblogic.allow.write.weblogic.workspace=everyone
              # JOLT FOR WEBLOGIC PROPERTIES
              # These properties configure a BEA Jolt connection pool for use with
              # the simpapp and bankapp examples, and register a servlet for use with
              # with the simpapp example. The default server address provided here
              # points to a public TUXEDO server that is hosted by BEA for use with
              # this example.
              # Servlet registration for simpapp example:
              #weblogic.httpd.register.simpapp=examples.jolt.servlet.simpapp.SimpAppServle
              t
              # Pool creation and cleanup
              # note this example is set up to work with the public
              # demo TUXEDO server available from BEA's website:
              #weblogic.system.startupClass.demojoltpoolStart=\
              # bea.jolt.pool.servlet.weblogic.PoolManagerStartUp
              #weblogic.system.startupArgs.demojoltpoolStart=\
              # poolname=demojoltpool,\
              # appaddrlist=//beademo1.beasys.com:8000,\
              # failoverlist=//beademo1.beasys.com:8000,\
              # minpoolsize=1,\
              # maxpoolsize=3
              #weblogic.system.shutdownClass.demojoltpoolStop=\
              # bea.jolt.pool.servlet.weblogic.PoolManagerShutDown
              #weblogic.system.shutdownArgs.demojoltpoolStop=\
              # poolname=demojoltpool
              # WEBLOGIC ENTERPRISE CONNECTIVITY PROPERTIES
              # The registrations enable a BEA IIOP connection pool and
              # register servlets for use with the simpapp and university examples.
              # Configure for your environment and uncomment to use.
              # Uncommenting these properties requires WebLogic Enterprise Connectivity
              # and an operating WebLogic Enterprise Server.
              # Servlet registration for simpapp servlet example
              #weblogic.httpd.register.SimpappServlet=\
              # examples.wlec.servlets.simpapp.SimpappServlet
              #weblogic.allow.execute.weblogic.servlet.SimpappServlet=everyone
              # Servlet registration for simpapp EJB example
              # (You'll need to add the wlec_ejb_simpapp.jar to the
              # weblogic.ejb.deploy property in this file.)
              #weblogic.httpd.register.ejbSimpappServlet=\
              # examples.wlec.ejb.simpapp.ejbSimpappServlet
              #weblogic.allow.execute.weblogic.servlet.ejbSimpappServlet=everyone
              # Pool creation and cleanup for the simpapp example
              #weblogic.CORBA.connectionPool.simplepool=\
              # appaddrlist=//wlehost:2468,\
              # failoverlist=//wlehost:2468,\
              # minpoolsize=2,\
              # maxpoolsize=3,\
              # username=wleuser,\
              # userrole=developer,\
              # domainname=simpapp
              # Servlet registration for university Servlet example:
              #weblogic.httpd.register.UniversityServlet=\
              # examples.wlec.servlets.university.UniversityServlet
              #weblogic.allow.execute.weblogic.servlet.UniversityServlet=everyone
              # Pool creation and cleanup for the University example:
              #weblogic.CORBA.connectionPool.Univpool=\
              # appaddrlist=//wlehost:2498,\
              # failoverlist=//wlehost:2498,\
              # minpoolsize=2,\
              # maxpoolsize=3,\
              # username=wleuser,\
              # userrole=developer,\
              # apppassword=wlepassword,\
              # domainname=university
              # WEBLOGIC FILE PROPERTIES
              # Maps a volume name to a path, for client file read/write
              #weblogic.io.fileSystem.[volumeName]=[fullPathName]
              # WEBLOGIC JMS DEMO PROPERTIES
              # CLUSTER USERS: Note that ALL JMS deployment should be done in the
              # per-cluster properties file ONLY.
              # You set up a JDBC connection pool if you want persistent messages
              # (including durable subscriptions). To use JMS and EJBs in the same
              # transaction, both must use the same JDBC connection pool. Uncomment
              # the following property to use the default JDBC connection pool
              # 'demo', which is defined in the Demo connection pool section of this file.
              #weblogic.jms.connectionPool=demoPool
              # The JMS Webshare example demonstrates how the ClientID for a
              # durable subscriber is configured in the connection factory:
              #weblogic.jms.topic.webshareTopic=jms.topic.webshareTopic
              #weblogic.jms.connectionFactoryName.webshare=jms.connection.webshareFactory
              #weblogic.jms.connectionFactoryArgs.webshare=ClientID=webshareUser
              #weblogic.httpd.register.webshare=examples.jms.webshare.WebshareServlet
              # The JMS trader example shows how to use JMS with an EJB. In addition
              # to uncommenting the following properties, you must also set up and
              # deploy the EJB example examples.ejb.basic.statelessSession.Trader in
              # ejb_basic_statelessSession.jar to try out this JMS example:
              #weblogic.jms.topic.exampleTopic=javax.jms.exampleTopic
              #weblogic.jms.connectionFactoryName.trader=jms.connection.traderFactory
              #weblogic.jms.connectionFactoryArgs.trader=ClientID=traderReceive
              #weblogic.httpd.register.jmstrader=examples.jms.trader.TraderServlet
              # Registers the underlying servlet
              #weblogic.httpd.register.jmssender=examples.jms.sender.SenderServlet
              # These properties are used with the ServerReceive JMS example,
              # which demonstrates how to establish a JMS message consumer
              # in a startup class:
              #weblogic.system.startupClass.serverReceive=\
              # examples.jms.startup.ServerReceive
              #weblogic.system.startupArgs.serverReceive=\
              # connectionFactory=javax.jms.TopicConnectionFactory,\
              # topic=javax.jms.exampleTopic
              # These properties are used with the PoolReceive JMS example,
              # which demonstrates how to establish a pool of JMS message consumers
              # in a startup class:
              #weblogic.system.startupClass.poolReceive=\
              # examples.jms.startup.PoolReceive
              #weblogic.system.startupArgs.poolReceive=\
              # connectionFactory=javax.jms.TopicConnectionFactory,\
              # topic=javax.jms.exampleTopic
              #weblogic.allow.create.weblogic.jms.ServerSessionPool=everyone
              # WEBLOGIC RMI DEMO PROPERTIES
              # CLUSTER USERS: Note that pinned RMI objects should be registered
              # in the per-server properties file ONLY. All other RMI startup
              # classes should be registered in the per-cluster properties file.
              # Remote classes registered at startup after the pattern:
              #weblogic.system.startupClass.[virtualName]=[fullPackageName]
              # These examples can be compiled to see RMI in action. Uncomment to use:
              #weblogic.system.startupClass.hello=examples.rmi.hello.HelloImpl
              #weblogic.system.startupClass.multihello=examples.rmi.multihello.HelloImpl
              #weblogic.system.startupClass.stock=examples.rmi.stock.StockServer
              # WEBLOGIC EJB DEMO PROPERTIES
              # CLUSTER USERS: Note that ALL EJB deployment should be done in the
              # per-cluster properties file ONLY.
              # See WebLogic Demo Connection Pool below for a connection pool
              # to use with these examples.
              # Deploys EJBeans. Uncomment the appropriate lines below and
              # modify DBMS-related info and paths to match your particular installation:
              #weblogic.ejb.deploy=\
              # g:/weblogic/myserver/ejb_basic_beanManaged.jar, \
              # g:/weblogic/myserver/ejb_basic_containerManaged.jar, \
              # g:/weblogic/myserver/ejb_basic_statefulSession.jar, \
              # g:/weblogic/myserver/ejb_basic_statelessSession.jar, \
              # g:/weblogic/myserver/ejb_extensions_finderEnumeration.jar, \
              # g:/weblogic/myserver/ejb_extensions_readMostly.jar, \
              # g:/weblogic/myserver/ejb_subclass.jar, \
              # g:/weblogic/myserver/jolt_ejb_bankapp.jar
              # Servlet used by the EJB basic beanManaged example
              # Uncomment to use:
              #weblogic.httpd.register.beanManaged=\
              # examples.ejb.basic.beanManaged.Servlet
              # Add a list of users (set the password with
              weblogic.password.[username]=XXX)
              # to set an ACL for this servlet:
              #weblogic.allow.execute.weblogic.servlet.beanManaged=user1,user2,etc
              #weblogic.password.user1=user1Password
              #weblogic.password.user2=user2Password
              # WEBLOGIC XML DEMO PROPERTIES
              # These properties are required to run the XML examples.
              # Uncomment to use.
              # CLUSTER USERS: Note that ALL servlets should be set up
              # in the per-cluster properties file ONLY.
              #weblogic.httpd.register.StockServlet=examples.xml.http.StockServlet
              # BizTalk example properties
              #weblogic.jms.queue.tradeIncoming=biztalk.jms.tradeIncoming
              #weblogic.jms.queue.tradeError=biztalk.jms.tradeError
              #weblogic.httpd.register.BizTalkServer=examples.xml.biztalk.BizHttpProtocolA
              dapter
              #weblogic.httpd.initArgs.BizTalkServer=bizQueue=biztalk.jms.tradeIncoming
              # WEBLOGIC ZAC DEMO PROPERTIES
              # These registrations enable the ZAC Publish Wizard.
              weblogic.zac.enable=true
              # Set the publish root for a WebLogic Server. Edit and
              # uncomment to use.
              #weblogic.zac.publishRoot=g:/weblogic/zac
              # Set an ACL for each package you publish. The [name] is
              # the "Package name" you assign in the ZAC Publish Wizard.
              # Publish a package, edit this property, and uncomment to use.
              #weblogic.allow.read.weblogic.zac.[name]=[user list]
              #weblogic.allow.write.weblogic.zac.[name]=system
              # HTTPD ADMINISTRATIVE PROPERTIES
              # Enables logging of HTTPD info in common log format and
              # sets the log file name (default is "access.log" in "myserver")
              weblogic.httpd.enableLogFile=true
              weblogic.httpd.logFileName=access.log
              # Tracks HTTPD requests with events delivered to WEBLOGIC.LOG.HTTPD
              weblogic.httpd.enableEvents=false
              # Enables HTTP sessions
              weblogic.httpd.session.enable=true
              # Sets an optional cookie name. The default name is "WebLogicSession".
              # Prior to version 4.0, the default was "TengahSession". To make
              # this backward compatible with cookies generated from previous
              # installations, you should set this property to "TengahSession".
              # Uncomment this line and set this to any string of your choice,
              # or comment out this property to use the default.
              #weblogic.httpd.session.cookie.name=WebLogicSession
              # MIME types
              weblogic.httpd.mimeType.text/html=html,htm
              weblogic.httpd.mimeType.image/gif=gif
              weblogic.httpd.mimeType.image/jpeg=jpeg,jpg
              weblogic.httpd.mimeType.application/pdf=pdf
              weblogic.httpd.mimeType.application/zip=zip
              weblogic.httpd.mimeType.application/x-java-vm=class
              weblogic.httpd.mimeType.application/x-java-archive=jar
              weblogic.httpd.mimeType.application/x-java-serialized-object=ser
              weblogic.httpd.mimeType.application/octet-stream=exe
              weblogic.httpd.mimeType.text/vnd.wap.wml=wml
              weblogic.httpd.mimeType.text/vnd.wap.wmlscript=wmls
              weblogic.httpd.mimeType.application/vnd.wap.wmlc=wmlc
              weblogic.httpd.mimeType.application/vnd.wap.wmlscriptc=wmlsc
              weblogic.httpd.mimeType.image/vnd.wap.wbmp=wbmp
              # In seconds, the keep-alive for HTTP and HTTPS requests
              weblogic.httpd.http.keepAliveSecs=60
              weblogic.httpd.https.keepAliveSecs=120
              # WEBLOGIC JDBC DRIVER PROPERTIES
              # Enables JDBC driver logging and sets the file name for the log
              # The weblogic.jdbc.logFile is placed in the per-server
              # directory (default is "myserver")
              weblogic.jdbc.enableLogFile=false
              weblogic.jdbc.logFileName=jdbc.log
              # WEBLOGIC JDBC CONNECTION POOL MANAGEMENT
              # CLUSTER USERS: Note that ALL JDBC connection pools should be set up
              # in the per-cluster properties file ONLY.
              # For creating JDBC connection pools. This example shows a connection
              # pool called "oraclePool" that allows 3 T3Users "guest," "joe," and "jill"
              # to use 4 JDBC connections (with a potential for up to 10 connections,
              # incremented by two at a time, with a delay of 1 second between each
              # attempt to connect to the database), to an Oracle database server called
              # "DEMO." If more than 4 connections are opened, after 15 minutes, unused
              # connections are dropped from the pool until only 4 connections remain
              open.
              # Every 10 minutes, any unused connections in the pool are tested and
              # refreshed if they are not viable.
              #weblogic.jdbc.connectionPool.oraclePool=\
              # url=jdbc:weblogic:oracle,\
              # driver=weblogic.jdbc.oci.Driver,\
              # loginDelaySecs=1,\
              # initialCapacity=4,\
              # maxCapacity=10,\
              # capacityIncrement=2,\
              # allowShrinking=true,\
              # shrinkPeriodMins=15,\
              # refreshMinutes=10,\
              # testTable=dual,\
              # props=user=SCOTT;password=tiger;server=DEMO
              # Get more details on each argument for this property in the
              # Administrators Guide on setting properties at:
              # http://www.weblogic.com/docs51/admindocs/properties.html
              # Set up ACLs for this connection pool with the following:
              #weblogic.allow.reserve.weblogic.jdbc.connectionPool.oraclePool=\
              # guest,joe,jill
              #weblogic.allow.reset.weblogic.jdbc.connectionPool.oraclePool=\
              # joe,jill
              #weblogic.allow.shrink.weblogic.jdbc.connectionPool.oraclePool=\

    Problem Resolved!
              I found out that I had 'http' instead of 'httpd' in the statement where I
              registered my servlet, SqlServlet.
              Now, I am having difficulty with hot deployment. The server is returning
              error 404.
              

Maybe you are looking for