uPortal IRC Logs-2012-12-14

Owned by Apereo Infrastructure
Last updated: Dec 14, 2012
4 min read

[09:33:29 CST(-0600)] <dd_> EricDalquist: hello, i was in here last week asking about jmeter testing, had a quick question, you available?

[09:33:37 CST(-0600)] <EricDalquist> sort of

[09:33:38 CST(-0600)] <EricDalquist> you can ask (smile)

[09:34:53 CST(-0600)] <dd_> i have a constant throughput timer on my test sequence of 60, so 1 req/sec. at the beginning of my test i make a GET request to extract the lt, then a POST request to login

[09:35:08 CST(-0600)] <dd_> after awhile i start to get errors on the POST request, from jmeter's log: The delay timer was interrupted - probably did not wait as long as intended.

[09:35:37 CST(-0600)] <dd_> and it is returning the login page in the response in the View Results Tree

[09:36:21 CST(-0600)] <dd_> so i don't know if it gets the lt, then it waits too long to make the POST on certain threads?

[09:36:42 CST(-0600)] <EricDalquist> that could be

[09:36:49 CST(-0600)] <EricDalquist> so jmeter has a tree structure

[09:37:14 CST(-0600)] <EricDalquist> create a few Simple Controllers

[09:37:24 CST(-0600)] <EricDalquist> and move group bits under those

[09:37:41 CST(-0600)] <EricDalquist> so create a Login simple controlelr and all of the login steps under it

[09:37:54 CST(-0600)] <EricDalquist> then add the portal interactions under another simple controller

[09:38:15 CST(-0600)] <EricDalquist> and move the constant throughput timer under the portal interaction group as well

[09:38:27 CST(-0600)] <EricDalquist> then the constant throughput timer will only apply to the samplers in that subtree

[09:38:53 CST(-0600)] <dd_> ok, so then the login samplers will just go as fast as it can?

[09:38:59 CST(-0600)] <EricDalquist> yeah

[09:39:16 CST(-0600)] <dd_> cool, thanks. i'll try that out

[09:39:17 CST(-0600)] <EricDalquist> and then that thread will end up waiting in the portal interaction section

[09:40:26 CST(-0600)] <dd_> could i use a TransactionController instead so it can just show up as Login in my results?

[09:40:47 CST(-0600)] <EricDalquist> not sure

[09:40:48 CST(-0600)] <EricDalquist> you could try

[09:40:54 CST(-0600)] <EricDalquist> I've never used that controller before

[10:31:24 CST(-0600)] <b-sure> hello uPortal devs. I've run into an issue with our 4.0.5 build where after a time of normal operation over several days, the portal stops rendering. no erros are in the portal log, but in localhost log we see a bunch of errors like this http://pastebin.com/raw.php?i=auXbish9

[10:32:37 CST(-0600)] <b-sure> I was getting help here last week or the week before about a related or possibly the same issue. I'm not sure if that paste has any more new information.

[10:33:06 CST(-0600)] <EricDalquist> so .... apparently this exception isn't getting logged by anything in uPortal

[10:33:08 CST(-0600)] <EricDalquist> which is a problem

[10:33:15 CST(-0600)] <EricDalquist> because the root cause is getting truncated by tomcat

[10:34:18 CST(-0600)] <b-sure> yeah. thats what you were saying last time. I wonder if there is some logging I could add to one of the source files that would give more info or perhaps uncover a further trace.

[10:35:34 CST(-0600)] <EricDalquist> sure

[10:35:52 CST(-0600)] <EricDalquist> so an easy palce to add something would be in UserLayoutManagerFactory

[10:35:54 CST(-0600)] <b-sure> I'm thinking maybe the AuthenticationDispatcherServlet but maybe there is a better file to use

[10:35:56 CST(-0600)] <EricDalquist> around lin 55

[10:36:02 CST(-0600)] <EricDalquist> catch exception and log it

[10:36:07 CST(-0600)] <b-sure> ok. I can do that.

[10:36:09 CST(-0600)] <EricDalquist> the better would be to write a simple Filter object

[10:36:20 CST(-0600)] <EricDalquist> that doesn't do any logic

[10:36:26 CST(-0600)] <b-sure> we won't be deploying until Tuesday but I can have it in the build by then

[10:36:35 CST(-0600)] <EricDalquist> but simply wraps chain.doFilter() in a try/catch

[10:36:41 CST(-0600)] <EricDalquist> and logs then re-throws all exceptions

[10:36:52 CST(-0600)] <EricDalquist> that would be a more robust solution

[10:37:02 CST(-0600)] <b-sure> ok. where would the filter be in the chain?

[10:37:07 CST(-0600)] <EricDalquist> and something we'd easily merge into uPOrtal

[10:37:09 CST(-0600)] <EricDalquist> first

[10:37:17 CST(-0600)] <EricDalquist> so you can declare the filter in web.xml

[10:37:42 CST(-0600)] <EricDalquist> make it the first filter-mapping in the file

[10:37:48 CST(-0600)] <b-sure> ok

[10:37:54 CST(-0600)] <EricDalquist> and apply it to

[10:37:54 CST(-0600)] <EricDalquist> <url-pattern>/*</url-pattern>

[10:38:00 CST(-0600)] <b-sure> yeah

[10:38:16 CST(-0600)] <b-sure> I didn't realize that exceptions could be logged there

[10:38:17 CST(-0600)] <EricDalquist> it won't need any spring references or anything

[10:38:27 CST(-0600)] <EricDalquist> so by doing that

[10:38:38 CST(-0600)] <EricDalquist> it will be added to the call stack on any portal excetion

[10:39:09 CST(-0600)] <b-sure> so where does it catch the exception in doFilter()

[10:39:28 CST(-0600)] <b-sure> rather how would the exception be caught there.

[10:39:40 CST(-0600)] <b-sure> oh wrap the chain in try/catch

[10:39:41 CST(-0600)] <EricDalquist> you would do soemthing like:

[10:40:03 CST(-0600)] <EricDalquist> try {

[10:40:03 CST(-0600)] <EricDalquist> chain.doFilter(req, res);

[10:40:03 CST(-0600)] <EricDalquist> }

[10:40:03 CST(-0600)] <EricDalquist> catch (Throwable e) {

[10:40:03 CST(-0600)] <EricDalquist> }

[10:40:05 CST(-0600)] <EricDalquist> actually

[10:40:08 CST(-0600)] <EricDalquist> let me gist this

[10:41:39 CST(-0600)] <EricDalquist> https://gist.github.com/4286786

[10:41:43 CST(-0600)] <b-sure> do you have a preference of the location of this filter or package?

[10:41:45 CST(-0600)] <EricDalquist> that will catch every throwable

[10:42:09 CST(-0600)] <EricDalquist> org.jasig.portal.utils.web

[10:42:12 CST(-0600)] <EricDalquist> would be decent

[10:43:26 CST(-0600)] <b-sure> ok. thanks. I'll let you know how it goes. not that I want the error to keep happening but hopefully this will give enough info to look into further

[10:43:39 CST(-0600)] <EricDalquist> the filter should ensure that any exception ends up in the portal log as well

[10:43:51 CST(-0600)] <EricDalquist> and that should capture the full stack trace

[10:43:57 CST(-0600)] <b-sure> yeah thats what had me spinning my wheels initiall