brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-386) NPE on rebind calling CreateUserPolicy.addUser
Date Tue, 15 Nov 2016 09:56:58 GMT

    [ https://issues.apache.org/jira/browse/BROOKLYN-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666704#comment-15666704
] 

Aled Sage commented on BROOKLYN-386:
------------------------------------

On rebind, the following happens:
* Entity is instantiated, but not yet managed; it therefore has a {{QueueingSubscriptionManager}}
* Entity's locations are re-added via AbstractEntity.addLocations(); this calls {{sensors().emit(AbstractEntity.LOCATION_ADDED,
loc)}}
* These attribute-changed publications are queued inside the {{QueueingSubscriptionManager}}
* The Entity's policies are added; {{CreateUserPolicy.setEntity}} subscribes to {{LOCATION_ADDED}}
events (which is registered in the {{QueueingSubscriptionManager}})
* The entity becomes managed: the {{QueueingSubscriptionManager}} is drained.
* in {{EntityManagementSupport.onManagementStarting}}, it replays the {{QueueingSubscriptionManager.queuedSubscriptions}}
(so now the policy's subscription is active)
* in {{EntityManagementSupport.onManagementStarted}}, it replays the {{QueueingSubscriptionManager.queuedSensorEvents}}
(including the locationAdded event, which is received by the policy)
* The policy executes {{onEvent}}, which triggers (asynchronously) adding the user to the
machine.

Three ways I see to fix this are:
1. Avoid publishing location-changed events when just re-adding the locations on rebind.
2. Replay the queued subscribe/publish in a smarter way, so they correctly interleave (i.e.
events 'published' before the 'subscribe' would not be received)
3. Change when {{policy.setEntity()}} is called, so that it is only done when the entity is
managed.
4. Guard against duplicate events inside {{CreateUserPolicy}}.

For (1), that makes sense to me. We already do something similar when re-setting the attributes
on rebind (calling {{entity.setAttributeWithoutPublishing()}}).

For (2), it becomes less of an issue if we've done (3), but still would be nice to have as
it feels like a more general problem. However, this is fiddly! The subscribe/publish replays
are called from different methods. Changing the order may have subtle consequences on other
entity/policy implementations!

For (3), I'll discuss that on the dev@brooklyn mailing list.

For (4), that is the easiest thing to do. But other policies/enrichers could still hit the
same problem.


> NPE on rebind calling CreateUserPolicy.addUser
> ----------------------------------------------
>
>                 Key: BROOKLYN-386
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-386
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Aled Sage
>
> I found this NullPointerException in the log:
> {noformat}
> 2016-09-07 13:50:40,633 INFO  o.a.b.c.m.r.RebindIteration [brooklyn-execmanager-EVQzoN78-0]:
Rebind complete (MASTER) in 41.0s: 6 apps, 16 entities, 56 locations, 2 policies, 88 enrichers,
0 feeds, 162 catalog items
> 2016-09-07 13:50:40,633 DEBUG o.a.b.c.m.r.RebindIteration [brooklyn-execmanager-EVQzoN78-0]:
RebindManager complete; apps: [fxky5xbx0z, vt864wmzpn, u3ohrxr21o, X0UTBSWZ, sJslLEBo, eb95zYiG]
> 2016-09-07 13:50:40,634 INFO  o.a.b.p.j.os.CreateUserPolicy [brooklyn-execmanager-EVQzoN78-0]:
Adding auto-generated user myname @ 1.2.3.4:11071
> 2016-09-07 13:50:40,667 DEBUG o.a.b.c.m.r.RebindManagerImpl [main]: Starting persistence
(org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl@19d095d5[mgmt=EVQzoN78]), mgmt EVQzoN78
> 2016-09-07 13:50:40,668 DEBUG o.a.b.l.j.JcloudsSshMachineLocation [brooklyn-execmanager-EVQzoN78-0]:
Problem getting node-metadata for SshMachineLocation[MyVcloudDirector(Test):amp@1.1.1.1/1.1.1.1:11071(id=N1UFSoVb)],
node id urn:vcloud:vm:be3270fd-698f-4be3-b8
> 55-d379505ac95a (continuing)
> java.lang.NullPointerException: null
>         at org.apache.brooklyn.location.jclouds.JcloudsSshMachineLocation.getOptionalNode(JcloudsSshMachineLocation.java:225)
[brooklyn-locations-jclouds-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.location.jclouds.JcloudsSshMachineLocation.getOptionalOperatingSystem(JcloudsSshMachineLocation.java:519)
[brooklyn-locations-jclouds-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.location.jclouds.JcloudsSshMachineLocation.inferMachineDetails(JcloudsSshMachineLocation.java:543)
[brooklyn-locations-jclouds-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.location.ssh.SshMachineLocation.getMachineDetails(SshMachineLocation.java:1058)
[brooklyn-core-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.policy.jclouds.os.CreateUserPolicy.addUser(CreateUserPolicy.java:145)
[brooklyn-locations-jclouds-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.policy.jclouds.os.CreateUserPolicy$1.run(CreateUserPolicy.java:114)
[brooklyn-locations-jclouds-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.util.concurrent.CallableFromRunnable.call(CallableFromRunnable.java:43)
[brooklyn-utils-common-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
[brooklyn-core-0.10.0-20160907.0931.jar:0.10.0-20160907.0931]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_95]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_95]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_95]
>         at java.lang.Thread.run(Thread.java:745) [na:1.7.0_95]
> {noformat}
> It shouldn't try to create the user again on rebind. And we should check to avoid the
NPE as well.
> But this is benign, given that we don't want it to be executing the create-user code
again anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message