If this happens, your current sessions will be lost unless you have configured a persistent session store. Some users have reported that if their application uses a lot of cookies, the browser will start to discard older cookies to make room for the new. This may result in the browser discarding the cookie that Resin is using to keep track of the session.
If your application uses a lot of cookies, the best solution is to reduce the number of cookies and size of cookie data. Resin uses a single cookie with a relatively small amount of data for tracking the session id of the user. Information that the application stores in cookies can be stored in the HttpSession object instead. However URL rewriting is not recommended because of security issues, the high probabilty that the application is missing calls to cause the rewriting on some pages, and because of the effect that rewriting has on the url.
You may also lose your sessions if your cookie domains are incompatible. For example, if you have one server that uses cookie domain "hogwarts. The solution is to change the cookie domain "hogwarts. If you forget to rewrite a URL, a user who requires rewriting will lose their session as soon as they follow that URL. Resin establishes an association between a session and a user's browser by establishing a unique id that is returned back with each new request.
This is accomplished in one of two ways: using cookies or URL rewriting. Resin first attempts to track the session of a user by sending the user's browser a cookie containing the unique session id.
Sometimes Resin cannot establish a cookie, either because the user has disabled cookies in their browser or because the browser does not support them as is the case with some HDML and WML browsers.
If the cookie cannot be established then something called URL rewriting is used. Then for each incoming request the first thing it does is look for this parameter, and if it is available it knows a session has been established and it removes the parameter and uses it to find the users session object.
Rewriting requires the cooperation of the developer. This error usually happens when a conflicting jar is found, see Clean up the classpath. If the classpath is completely cleaned up, as suggested in the link, then a jar or some other component of a jdk installation or older Resin installation is coming from somewhere else.
If on windows, check for stray copies of java. Debug logging will show the request coming into to Resin, and provide some information on how Resin is dealing with the post. The browser will always send back parameters in the same encoding as the output page. Since the request doesn't include the encoding an oversight in the HTTP spec , the application code needs to make sure the encoding matches. So the first thing to do is to determine that encoding your form page has when it is sent to the browser.
Your application should always specify that. Having established that, you will know what encoding the browser is going to use for the POST. Then before reading the POST parameters make sure you set the encoding to match. You can call request. Resin provides a number of diagnostic messages using the JDK logging facility.
Full debug logging is enabled with an empty name meaning match all names and a level of 'all'. Since this will produce many messages, it is useful to put the messages in a a seperate file.
The following configuration creates a debug log for each day, and when a problem occurs the debug log is used to help find out what the problem is. More specific areas can be targetted with appropriate values for name.
Often you can narrow down the logging requirements to a single web application. If an application seems stuck, or is running out of resources, a thread dump will reveal the state of the server. Java's thread dumps are a vital tool for server debugging. Because servlets are intrinsically multithreaded, it is very possible to create deadlocks without realizing it, or to have runaway threads that consume resources and cause OutOfMemory exceptions.
The Solaris 1. You need to run Resin in the foreground i. Then you'll need to answer some questions on the console. You get a thread dump without signalling the process by starting the JVM with some extra arguments to allow a debugger to attach. You can then attach with the debugger at any time to get a thread dump. This technique works on all operating systems. Although no rigorous benchmarking has been done, there appears to be little overhead or performance penalties involved in having the JVM start with the options that allow a debugger to attach.
In any case, you'll eventually get a trace that looks something like the following each JDK is slightly different :. The tcp-accept-xxx thread should almost always be in socketAccept. There should be several tcpConnection-xxx-n threads. Each of these is the servlet thread.
On a busy server, these can appear anywhere in your code. If several appear in one location, you've likely got some sort of deadlock or at least a slow lock. Idle threads are either in tcpAccept or httpRequest or runnerRequest for keepalive threads. For deadlocks, you'll want to look at the "waiting on monitor" threads and any case where lots of threads are stuck at the same location.
Most memory problems are due to memory leaks in the application program. For example, a cache or a vector that fills up with stale data, or a singleton or static variable which doesn't properly detect a web-app reload. It's very convenient for checking basic memory usage and garbage collection time. It's a good idea to use -verbosegc for any production system. When starting Resin, you'll use -J-verbosegc.
The " K " is the most important number, showing that the maximum allocated heap is about 10 meg. The other numbers show the actual heap used before and after garbage collection. If an application gobbles up memory until it throws an OutOfMemory exception, or seems to be spending an excessive amount of time doing garbage collection, a heap dump can help track down the source of the problem. What you really need to do is get a good CPU and heap profile.
The JDK has a simple one but not very user-friendly , so you don't absolutely need to buy a profiler. An alternative for simple heap monitoring garbage collection issues , are the jvmstat tools. It's a standard java argument, so "java -Xrunhprof:help" will tell you how to start it. For example, you could start Resin unix or windows as. On Unix, Resin's startup script has a -cpuprof-ascii argument that sets it for you automatically.
Run a load against it for a decent amount of time you can even use something like Apache's "ab" for 10 minutes , and then stop the server nicely. Assuming you're being cheap, and using the JDK's heap profiling instead of buying a profiler, you'll need a bit of help interpreting it.
The following is an example of a heap dump running Resin. Join Date Mar Posts Re:customize DashBoard I'm interested in this too, though I have just started looking at. But to customize the dashboard that is currently there, depending on your install. Assuming PCI, pentaho-samples, samples, dashboard Perhaps some of the guru's from the pentaho team might be able to lend a hand.
I have also been looking at understanding the jboss portal that they are using. It's probably not much help but it's my 2cents.
Try not to have too much fun. Join Date Nov Posts Look for JBoss Portal Customization. So it looks like i"m on the right track Re:customize DashBoard I figured I would come back here and report what I have discovered about customizing the dashboard or anypart of the jboss portal. Then you need to read the session and filter documentation from the download links.
Now your ready to start the process. Click the 'management' link in the pages portlet above where you set the theme at. Now you have created your instance of the portlet if your portlet was not in the list you defined something wrong and you'll need to go back and redefine it.
So now it'e runnng and you have an instance of it. The fun part is placing it on a portal page. Select "Portal" Dill down to "[07]Dashboard" and you'll see it already has 5 portlets defined in it which you can distory by selecting and clicking destroy. Click the Dashboard and you'll get some interesting looking stuff on the far right. Here you need to select the Instance of the portlet you create in the drop down box and enter a name for it in the text box then under the part of the page you want it to appear click the "Create instance" button under it.
So to sum this up. It's really not too tough. See other portlet examples in the portlet. This is just a start not a finite guide, but it should help. Have a nice day and please drive through, Nic PS to the pentaho guys or ANYone that has already done the such please add comments about missed steps, details and comments.
Re:customize DashBoard Using the SDK with quite abit more digging into the dashboard seen I came to discover answers to some questions as well as found more questions. First of which is where do the files that get compiled to create the pentaho-object. Some of the other things I discover in regrads to building a dashboard in Jboss portal. Also defined in the portlet. I think this might help other to understand how complex getting the bashboard to actual interact with pentaho using jboss portal.
So to sum it up you'll need to define your portlets in portlet. These charts and widgets are based off of information gerentated from the xactions output variables that the chart and widget is defined to used. Then Define the layout of the portal page in pentaho-object. You can set this in your build files - assuming ant it would look like this: XML. Posted Mar am Arndt Faulhaber.
Add your solution here. OK Paste as. Treat my content as plain text, not as HTML. Existing Members Sign in to your account. This email is in use. Do you need your password? Submit your solution! When answering a question please: Read the question carefully. Understand that English isn't everyone's first language so be lenient of bad spelling and grammar. If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question. Let's work to help developers, not make them feel stupid.
0コメント