[
https://issues.apache.org/jira/browse/SLIDER-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005402#comment-16005402
]
Manoj Samel edited comment on SLIDER-1227 at 5/10/17 9:06 PM:
--------------------------------------------------------------
Billie Rinaldi explained the roleGroup feature that causes the effect above.
Thinking a bit more about the roleGroup feature, following are my thoughts ...
For a component, it seems user will either specify explicit name (as in above
case) OR will have a group like ZOOKEEPER where slider generates unique
component names like ZOOKEEPER_n (n=1,2..). If this is true, then I feel it
would be cleaner design to explicitly introduce a new entity called the group.
In metaInfo.xml, one <component> element can either have <name> or have <group>
but not both. When <name> is specified, the code should not parse for a group
within the container name. When <group> is specified, the code will generate
individual component names and expect to parse group back from container name.
This will not just solve the current reported problem but will also make it
clearer for slider users to understand and implement groups.
was (Author: manojsamel):
Billie Rinaldi explained the roleGroup feature that causes the effect above.
Thinking a bit more about the roleGroup feature, following are my thoughts ...
It seems user will either specify explicit component names for each component
(as in my case) OR will have a group like ZOOKEEPER where slider generates
unique component names like ZOOKEEPER_n (n=1,2..). If this is true, then I feel
it would be cleaner design to explicitly introduce a new entity called the
group. In metaInfo.xml, one <component> element can either have <name> or have
<group> but not both. When <name> is specified, the code should not parse for a
group. When <group> is specified, the code will generate individual component
names and expect to parse group back from container name.
This will not just solve the current reported problem but will also make it
clearer for slider users to understand and implement groups.
> Component name with 3 "_" gives NPE in 0.92, is working in 0.80
> ---------------------------------------------------------------
>
> Key: SLIDER-1227
> URL: https://issues.apache.org/jira/browse/SLIDER-1227
> Project: Slider
> Issue Type: Bug
> Components: core
> Affects Versions: Slider 0.92
> Reporter: Manoj Samel
>
> Running slider 0.92 on CDH 5.5.1 (which is Hadoop 2.6), with Kerberos
> I am deploying a application with multiple components. The components start
> but fail to heart beat to slider AM. The slider AM log shows NPE at container
> heartbeat URLs as below.
> 2017-04-12 00:44:05,741 [2011871076@qtp-814377348-5] INFO
> agent.AgentProviderService - Handling registration: responseId=-1
> timestamp=1491957845550
> label=container_e95_1476898378926_91401_01_000003___solo___super
> hostname=node1078
> expectedState=INIT
> actualState=INIT
> appVersion=null
> 2017-04-12 00:44:05,741 [2011871076@qtp-814377348-5] INFO
> agent.AgentProviderService - label:
> container_e95_1476898378926_91401_01_000003___solo___super pkg: null
> 2017-04-12 00:44:05,741 [2011871076@qtp-814377348-5] INFO
> agent.AgentProviderService - Registration response:
> RegistrationResponse{response=OK, responseId=0, statusCommands=null}
> 2017-04-12 00:44:05,871 [Socket Reader #1 for port 32120] INFO ipc.Server -
> Auth successful for slideradmin@BIGDATA (auth:SIMPLE)
> 2017-04-12 00:44:05,873 [Socket Reader #1 for port 32120] INFO
> authorize.ServiceAuthorizationManager - Authorization successful for
> slideradmin@BIGDATA (auth:TOKEN) for protocol=interface
> org.apache.slider.server.appmaster.rpc.SliderClusterProtocolPB
> 2017-04-12 00:44:15,749 [1005856666@qtp-814377348-7] ERROR mortbay.log -
> /ws/v1/slider/agents/container_e95_1476898378926_91401_01_000002___pdx__svt___ten85/heartbeat
> java.lang.NullPointerException
> at
> org.apache.slider.providers.agent.AgentProviderService.handleHeartBeat(AgentProviderService.java:1090)
> at
> org.apache.slider.server.appmaster.web.rest.agent.AgentResource.heartbeat(AgentResource.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
> at
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
> at
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:699)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
> at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 2017-04-12 00:44:15,750 [2011871076@qtp-814377348-5] ERROR mortbay.log -
> /ws/v1/slider/agents/container_e95_1476898378926_91401_01_000004___pdx__svt___ten83/heartbeat
> java.lang.NullPointerException ....
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
