stacktrace on Bounce button in Agent View

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

stacktrace on Bounce button in Agent View

sodul
In the Agent view if I try to Bounce a component I always get a stacktrace (see below).

If I click Stop, it works, and I can then click Start. I can also filter to that component in the Dashboard view and create a Bounce plan. So not a big blocker.

This is with the 5.3.0 console and 5.0.0 agents (we will upgrade the agents to 5.3.0 this week).

[+] java.lang.NullPointerException: Cannot get property 'agent' on null object
at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:56)
at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:169)
at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at org.linkedin.glu.console.controllers.AgentsController$_closure16_closure46.doCall(AgentsController.groovy:336)
at sun.reflect.GeneratedMethodAccessor1244.invoke(Native Method)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1082)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1106)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:906)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:848)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:831)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:164)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeClosure(ScriptBytecodeAdapter.java:570)
at org.linkedin.glu.provisioner.core.model.ClosureSystemFilter.filter(ClosureSystemFilter.groovy:56)
at org.linkedin.glu.provisioner.core.model.SystemFilter$filter$0.call(Native Method)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.linkedin.glu.provisioner.core.model.SystemFilter$filter$0.call(Native Method)
at org.linkedin.glu.provisioner.core.model.LogicAndSystemFilterChain$_filter_closure1.doCall(LogicAndSystemFilterChain.groovy:32)
at sun.reflect.GeneratedMethodAccessor1245.invoke(Native Method)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1082)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1106)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:906)
at groovy.lang.Closure.call(Closure.java:412)
at groovy.lang.Closure.call(Closure.java:425)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1326)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1298)
at org.codehaus.groovy.runtime.dgm$148.invoke(Native Method)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:271)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at org.linkedin.glu.provisioner.core.model.LogicAndSystemFilterChain.filter(LogicAndSystemFilterChain.groovy:30)
at org.linkedin.glu.orchestration.engine.delta.impl.SystemFiltersDeltaSystemModelFilter.filter(SystemFiltersDeltaSystemModelFilter.java:46)
at org.linkedin.glu.orchestration.engine.delta.impl.SingleDeltaBuilder.computeFilteredKeys(SingleDeltaBuilder.java:326)
at org.linkedin.glu.orchestration.engine.delta.impl.SingleDeltaBuilder.getFilteredKeys(SingleDeltaBuilder.java:98)
at org.linkedin.glu.orchestration.engine.delta.impl.SingleDeltaBuilder.computeDependencies(SingleDeltaBuilder.java:260)
at org.linkedin.glu.orchestration.engine.delta.impl.SingleDeltaBuilder.<init>(SingleDeltaBuilder.java:72)
at org.linkedin.glu.orchestration.engine.delta.impl.MultiDeltaBuilder.<init>(MultiDeltaBuilder.java:54)
at org.linkedin.glu.orchestration.engine.delta.impl.DeltaMgrImpl.computeDeltas(DeltaMgrImpl.java:96)
at org.linkedin.glu.orchestration.engine.delta.DeltaMgr$computeDeltas.call(Native Method)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.linkedin.glu.orchestration.engine.delta.DeltaMgr$computeDeltas.call(Native Method)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl.doComputeDeploymentPlans(PlannerServiceImpl.groovy:155)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl.this$2$doComputeDeploymentPlans(Native Method)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl$this$2$doComputeDeploymentPlans$0.callCurrent(Native Method)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl$this$2$doComputeDeploymentPlans$0.callCurrent(Native Method)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl.computeDeploymentPlans(PlannerServiceImpl.groovy:132)
at org.linkedin.glu.orchestration.engine.planner.PlannerService$computeDeploymentPlans.callCurrent(Native Method)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl.computeBouncePlans(PlannerServiceImpl.groovy:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1082)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1106)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:78)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl$_computePlans_closure5.doCall(PlannerServiceImpl.groovy:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:272)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:64)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:69)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at org.linkedin.glu.groovy.utils.plugins.PluginServiceImpl.executePrePostMethods(PluginServiceImpl.groovy:106)
at org.linkedin.glu.groovy.utils.plugins.PluginService$executePrePostMethods.call(Native Method)
at org.linkedin.glu.orchestration.engine.planner.PlannerServiceImpl.computePlans(PlannerServiceImpl.groovy:292)
at org.linkedin.glu.orchestration.engine.planner.PlannerService$computePlans.call(Native Method)
at org.linkedin.glu.console.controllers.AgentsController$_closure16.doCall(AgentsController.groovy:347)
at org.linkedin.glu.console.controllers.AgentsController$_closure16.doCall(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:272)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:64)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at org.linkedin.glu.console.controllers.AgentsController.create_plan(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.grails.web.servlet.mvc.MixedGrailsControllerHelper.invoke(MixedGrailsControllerHelper.java:69)
at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleAction(AbstractGrailsControllerHelper.java:334)
at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.executeAction(AbstractGrailsControllerHelper.java:217)
at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleURI(AbstractGrailsControllerHelper.java:183)
at org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsControllerHelper.handleURI(AbstractGrailsControllerHelper.java:116)
at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:72)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:328)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1448)
at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:195)
at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:276)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:103)
at org.codehaus.groovy.grails.web.util.WebUtils.forwardRequestForUrlMappingInfo(WebUtils.java:314)
at org.codehaus.groovy.grails.web.util.WebUtils.forwardRequestForUrlMappingInfo(WebUtils.java:279)
at org.codehaus.groovy.grails.web.util.WebUtils.forwardRequestForUrlMappingInfo(WebUtils.java:270)
at org.codehaus.groovy.grails.web.mapping.filter.UrlMappingsFilter.doFilterInternal(UrlMappingsFilter.java:221)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.obtainContent(GrailsPageFilter.java:200)
at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.doFilter(GrailsPageFilter.java:151)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterInternal(GrailsWebRequestFilter.java:69)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.apache.shiro.grails.SavedRequestFilter.doFilter(SavedRequestFilter.java:55)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.codehaus.groovy.grails.web.filters.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:66)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:380)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Is this a new issue with 5.3.0? Or was it also the case before?

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
If you go on the Dashboard, filter by an agent only and select bounce, does it work?

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
Short answers:
 - I believe (not sure) it was buggy in 5.2.0 and maybe 5.1.0
 - Dashboard can bounce a single app on a single agent, no problem.

Longer answer:
I think we had the issue at least with 5.2.0, but since almost exclusively use the Dashboard with filters it never nagged anyone so we ignored it. I had to do some troubleshooting of a new component (hadoop) today and needed to bounce a lot, hence my report ;-)

It is a regression from earlier versions, I'm just not sure in what release of Glu it happened and I do not think it is new in 5.3.0.
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Well. I have been trying to reproduce the issue but cannot  (5.2.0 or 5.3.0). So here is the exact steps I am doing (in case I am misunderstanding what you are doing):

* using a fresh tutorial (which is now very easy to get to by simply deleting the tutorial folder and restarting the tutorial :)
* load the sample webapp model
* deploy it
* go to agent-1 view
* under /sample/i001 there is a series of button (View Details, ps, ...) and I click "Bounce" => this works and leads to the proper plan (which can get executed without any issue)
* go to agent-1 view again
* select tab "Plans".
* select Sequential or Parallel right next to Bounce => this works and leads to the proper plan (which can get executed without any issue)

I have repeated the same steps under 5.2.0 and 5.3.0 without any problem. Can you please detail what you are doing exactly?

Thanks
Yan
PS: I noticed that the name of the plan contains __role=xxx and will remove it in an upcoming release...
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
I'm able to reproduce in our QA and Prod environments. When clicking on the Bounce button in the agent view I get the stacktrace (shwoing up in red on top of the agent view) about 30% of the time, so I can bounce by retrying multiple times. The Plans view from the Dashboard view always work.

The Bounce button is the only one with the issue, Stop, Undeploy, etc... always work.

I have not been able to reproduce with the 5.3.0 tutorial.

We are upgrading our agents to 5.3.0 from 5.0.0 in the next couple of days, I'll let you know if 5.3.0 -> 5.3.0 improves things.
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Do you get the exception when you click the button to display the plan or when you execute the plan?

I seriously doubt it has anything to do with the agent. 5.3.0 agent only has changes in the getFileContent method to handle the new tail/directory feature.

I will try to take a look at the source code and your stack trace to try to reverse engineer what could go wrong (since I cannot reproduce).

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
I confirmed the issue with Console and Agents at 5.3.0.

I get the stack trace as soon as I click the button. I stay on the agent view page, instead of going to the Plans page. It displays the error in red just below the menus, with a '+' icon to click with the stacktrace details.

I'll give you a screen shot when I get back in the office tomorrow.
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
In reply to this post by frenchyan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
So I am a bit puzzled here. Here is the code that is failing:

      def system = request.system
      system = system.unfilter().filterBy {
        it.agent == params.id && it.mountPoint == params.mountPoint
      }

Technically a system filter (which is implemented as a Closure in this case) should handle the possibility that the SystemEntry passed to it (the "it" parameter) can be null. So by changing the code to:

        it?.agent == params.id && it?.mountPoint == params.mountPoint

this will certainly fix this specific problem.

But getting a null SystemEntry should be the case when computing the delta... not when simply filtering the system model that is coming from the current model.

I need to investigate in which case I generate a system model with null entries... that does not make a lot of sense.. and I just don't want to hide a much bigger issue...

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Actually I was wrong, it is not filtering the current system model (as in the live one), but the one that you loaded. I don't think it is possible to have null entries in it... but can you check by any chance?

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
I'm not sure what to check.

If you mean the entries in the json model, then they are all correct (I'm sending you my model over private message). Since this is happening randomly on the very same button for the very same mountpoint, it is indeed hard to reproduce.
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Yes nothing looks wrong in your model. And indeed the fact that is random is weird. Do you know if by any chance the model gets changed under your feet? Or is it pretty stable? Trying to think it could be thread safety issue... but if your model does not change, then that makes it harder...

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
No the model get regenerated on demand or once per day from Jenkins. I double checked the console's audit log and the model has not changed since yesterday and I still get the error randomly. I'm not seeing anything written to the console's log files when this happen either.

The other thing is that I do get the same behavior on both of my consoles (QA/Prod), but could not reproduce with the tutorial. And of course, all the other actions seem fine ... why only Bounce?

Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Well I think I know what the problem is. I was both right and wrong in my analysis. Indeed the exception does not happen when filtering the system, it is just not possible (you cannot have any null entry). But what I had not realized from the stack trace is that the exception actually happens later! 

at org.linkedin.glu.console.controllers.AgentsController$_closure16.doCall(AgentsController.groovy:347)

and this computes the delta. The closure is created and used right while filtering the model (line 335) but it gets reused later on to filter the live model when computing the delta. And as I mentioned before there are cases where the filter can be called with a null entry.

The reason why it is only Bounce, is most likely due to the fact that a special filter is created in the case of bounce (BounceDeltaSystemModelFilter).

In the end, this is related to this issue: https://github.com/pongasoft/glu/issues/242 and as you can see from the commit, I thought I had addressed all filters... https://github.com/pongasoft/glu/commit/5dc3edb86d7742b9be32474799897837c80221f3 Except I did not account for the anonymous/closure ones...

I am planning to release 5.3.1 with essentially this change tomorrow (Thursday) unless there are other pressing issues to include.

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
Great debugging work. As I said, not a showstopper for us, so no rush :-)

Other than that I'm vey happy with the new log viewer and the static urls. We can now add links in our wiki pages, bug reports, or just when troubleshooting things over IM. This release is definitely going to have a positive impact on our engineering productivity.
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
Really glad to hear. I have some other ideas for some other of your issues (like 173: Failed deployments show the head of the groovy script output, not tail) which should also help with the productivity. Sorry for taking so long. When I get back I will look into this. Now that I have the tail mechanism in place, it should be easier to iterate.

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
I actually have many suggestions on how to improve the remote log viewers (most wanted to least wanted):
 - option to view N lines (we have 1GB+ log files, and sometimes we want to see the last 10k lines)
 - resizable log section (the blue box where the log is shown, I have a 30" screen and having more lines on screen would be a big improvement)
 - show file permissions (uid, gid, etc...)
 - In the cell showing the full path (show/hide full path tooltip), make each item of the full path a link to that subdirectory.
 - sortable files in the directory view (sort by name, by date, by size)
 - eye candy: syntax highlighter (there are a bunch of open source javascript/css syntax highlighters around)
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

frenchyan
Administrator
>> - option to view N lines (we have 1GB+ log files, and sometimes we want to see the last 10k lines) 

It is pretty easy to do 10k bytes (which is what happens now)... it is much harder to do 10K lines... I don't know how tail implements it... but in the end if I had a way to know the offset in the file then it is easy...

>> - resizable log section (the blue box where the log is shown, I have a 30" screen and having more lines on screen would be a big improvement) 

I know that this wouldn't be resizable on demand, but you can always add a customCss section in your console defaults section to change the size by default:

.text-file-content #file-content {
  max-height: 500px;
}

It is set to 500px but you can change it to a much higher value.

It would also be nice if the console could remember those settings on a per user basis (like if you increase the font size or the wrapping of the lines...)... these are on my mind :)

Yan
Reply | Threaded
Open this post in threaded view
|

Re: stacktrace on Bounce button in Agent View

sodul
>> Tail size
AFAIK, tail recursively set the offset in chunk from the end load that in a buffer and count the lines in chunks and eventually running out of ram if the file is very large... At least that's how I remember reading the BSD tail source code.

It does not matter so much what the unit is as the possibility to get more. Being able to do last 10kB, last 50kB, etc... is still very useful.

Regardless of that, you should probably strip the first line of the buffer since it is very likely cut mid-line. This would show a much cleaner and less confusing output.

>> Log section size ... The way Jenkins does it is actually perfect, I'll play around with the css and let you know if I come up with something good.
12