jhg03a opened a new issue #3315: Assigning servers to ANY_MAP DS causes null pointer exception in TR URL: https://github.com/apache/trafficcontrol/issues/3315 There appears to be a regression in the CRConfig generation process where if you add servers to an ANY_MAP DS, those assignments leak into the CRConfig which causes TR to throw a exception. The suspected source is that DS assignments exist for a DS that shouldn't exist in the CRConfig. Found in the 3.x RC4 release and head of master at a86195f Exception thrown in TR (snipped): ``` WARN 2019-02-08T18:01:09.898 [New I/O worker #2] com.comcast.cdn.traffic_control.traffic_router.core.util.PeriodicResourceUpdater - java.lang.NullPointerException at com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.populateZoneMap(ZoneManager.java:642) at com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.generateZones(ZoneManager.java:364) at com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.initZoneCache(ZoneManager.java:187) at com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.<init>(ZoneManager.java:113) at com.comcast.cdn.traffic_control.traffic_router.core.router.TrafficRouter.<init>(TrafficRouter.java:114) at com.comcast.cdn.traffic_control.traffic_router.core.router.TrafficRouterManager.setCacheRegister(TrafficRouterManager.java:103) at com.comcast.cdn.traffic_control.traffic_router.core.config.ConfigHandler.processConfig(ConfigHandler.java:227) at com.comcast.cdn.traffic_control.traffic_router.core.monitor.TrafficMonitorWatcher$2.update(TrafficMonitorWatcher.java:116) at com.comcast.cdn.traffic_control.traffic_router.core.util.PeriodicResourceUpdater.updateDatabase(PeriodicResourceUpdater.java:165) at com.comcast.cdn.traffic_control.traffic_router.core.util.PeriodicResourceUpdater$UpdateHandler.onCompleted(PeriodicResourceUpdater.java:285) at com.comcast.cdn.traffic_control.traffic_router.core.util.PeriodicResourceUpdater$UpdateHandler.onCompleted(PeriodicResourceUpdater.java:256) ... snipped ... ``` If you remove the server assignments, then TR will be ok. However this also means that the ANY_MAP DS doesn't do anything. You can create an ANY_MAP DS as follows to reproduce: 1. Create and link the following parameters to your ATS Server profile: ``` a. name: location | configFile: anymap_hdr_rw.config | value: "/opt/trafficserver/etc/trafficserver" b. name: data | configFile: anymap_hdr_rw.config | value: "cond %{SEND_RESPONSE_HDR_HOOK} __RETURN__ add-header ATS_ANYMAP_GLOBAL 'Anymap_Global_Match' [L]" ``` 2. Create an ANY_MAP DS as normal using the following raw remap text field: `map / http://<replace.with.some.valid.origin>/ @plugin=header_rewrite.so @pparam=anymap_hdr_rw.config` 3. Assign some ATS Servers 4. Queue/snap the CDN containing your ANY_MAP DS: * This is presently where it will break TR. You will see that the server assignments are part of the snapshot diff in TP 5. Badass your ATS Servers to pull down the new anymap header rewrite config 6. Run a test curl against the ATS server fqdn for a known asset and observe that you now have a ATS_ANYMAP_GLOBAL header in your response as well as your known asset body.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
