Enterprise Distributed Application Service:Error code: HSF-0024

Quick diagnosis

Match your symptom to the most likely cause:

Log files

All troubleshooting steps reference hsf.log. Locate it based on your HSF version:

Step 1: Verify the call mode

Local calls and generic calls bypass the routing rule engine entirely. If the consumer uses either mode, routing rules have no effect.

Local call mode

When a process acts as both the service provider and the service consumer, HSF defaults to in-process Java calls instead of remote procedure calls (RPCs). Because no RPC occurs, the routing rule logic is never invoked.

Generic call mode

In generic call mode, the consumer invokes GenericService directly to describe the service without depending on the service's second-party package. Because HSF has no loaded service class in this mode, it cannot run the routing rule's service logic.

Note: The service test function in HSFOPS uses generic calls. Routing rules do not take effect when you test services through HSFOPS.

If the consumer uses standard RPC calls and the rule still has no effect, proceed to Step 2.

Step 2: Confirm the consumer received the rule

HSF stores routing rules in Diamond. When a consumer starts, it pulls the routing rules for each consumed service from Diamond.

Search hsf.log for the target service name. A successful pull produces a log entry similar to:

2015-10-09 13:20:06.402 WARN [com.taobao.diamond.client.Worker.default:t.hsf] [] [] [] [Metadata Component] Received rule for service [com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily]: Groovy_v200907@package hqm.test.groovy
public class RoutingRule{
    Map<String, List<String>> routingRuleMap(){
        return [
            "G1":["100.69.161.201:*"]
        ]
    }

    String interfaceRoutingRule(){
        return "G1";
    }
}

Look for the keyword [Metadata Component] Received rule for service followed by your service name.

If no matching log entry exists, check the following:

1. Rule-to-service name mismatch -- Verify that the routing rule name in Diamond matches the fully qualified service name (interface name + version).

2. Environment mismatch -- Confirm that the Diamond environment where the rule is configured matches the consumer's runtime environment.

Step 3: Confirm the rule parsed successfully

After receiving the rule, HSF parses the Groovy script. Search hsf.log for the service name. A successful parse produces a log entry similar to:

2015-10-09 13:20:06.761 INFO [com.taobao.diamond.client.Worker.default:t.hsf] [] [] [] Parse route rule successed, RouteRule:com.taobao.hsf.route.service.RouteRule@4441ec5a{
keyedRules={G1=[100.69.161.201:*]},
interfaceRule=G1,
methodRule={},
argsRule={}
}

Look for the keyword Parse route rule successed.

If parsing fails, the log contains an error with details about the Groovy syntax or structural issue. Review the error against the routing rule structure reference below.

Step 4: Validate the rule and address resolution

If the rule was received and parsed correctly, the problem lies in the rule logic or the address resolution process. Check these areas in order.

2015-10-09 13:20:06.761 WARN [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [Address Component] isEmptyProtection: true
2015-10-09 13:20:06.761 WARN [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [Address Component] newAllAvailableAddresses is empty for service : com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily
2015-10-09 13:20:06.761 INFO [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [AddressBucket-com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily] Refresh: all amount [0], available amount [0], local preferred switch [off].Unit=UNIT
2015-10-09 13:20:06.761 INFO [HSF-AddressAndRule-1-thread-1:t.hsf] [] [] [] [Address Component] route result com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily, addresses remain[1], EmptyProtection triggered [true]
2015-10-09 13:20:06.762 INFO [HSF-AddressAndRule-1-thread-1:t.hsf] [] [] [] [AddressBucket-com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily] Refresh: all amount [1], available amount [1], local preferred switch [off].

Step 5: Verify the rule executes at runtime

If all preceding steps pass, confirm that the target service method is actually called. If the method in the routing rule is never invoked, the rule never runs.

Add System.out.println() statements inside the routing rule to trace execution. For argsRoutingRule, the return value must be a closure. Example:

Groovy_v200907@package hqm.test.groovy
public class RoutingRule {
    Map<String, List<String>> routingRuleMap() {
        return [
            "BSeller_address_filter_Key":["10.177.75.54:*"],
            "ASeller_address_filter_Key":["10.97.94.33:*"]
        ]
    }

    Object argsRoutingRule(String methodName, String[] paramTypeStrs) {
        if (methodName.startsWith("checkUrlPermission")) {
            System.out.println("Match the checkUrlPermission method.");
            return {
                Object[] args ->
                if(args[1] % 2 == 1 ) {
                    System.out.println("Route to BSeller_address_filter_Key");
                    return "BSeller_address_filter_Key.";
                } else {
                    System.out.println("Route to ASeller_address_filter_Key");
                    return "ASeller_address_filter_Key." ;
                }
            }
        }
    }
}

Check the consumer's standard output for the printed messages. If no output appears, the method name does not match, or the method is never called.