Quantcast
Channel: Having full atomicity against all the threads without impacting performance or throughputs - Stack Overflow
Viewing all articles
Browse latest Browse all 3

Having full atomicity against all the threads without impacting performance or throughputs

$
0
0

I have a list of hostnames which I am supposed to make a call by making the proper URL from it. Let's say if I have four hostname (hostA, hostB, hostC, hostD) in the linked list -

  • Execute hostA url and if hostA is UP then get the data and return the response.
  • But if hostA is down, then add hostA to block list of hostnames and make sure no other thread is making call to hostA. And then try executing hostB url and return the response back.
  • But if hostB is also down, then add hostB to block list of hostnames as well and repeat the same thing.

Also, I have a background thread running in my application which will have the list of block hostnames (from my another service) which we are not supposed to make a call but it runs every 10 minutes so the list of block hostnames will get updated only after 10 minutes so if any block list of hostnames is present, then I won't make a call to that hostname from the main thread and I will try making a call to another hostname. Meaning if hostA is blocked, then it will have hostA present in the block list but if hostA is up, then that list will not have hostA in it.

Below is my background thread code which gets the data from my service URL and keep on running every 10 minutes once my application has started up. It will then parse the data coming from the URL and store it in a ClientData class variable -

TempScheduler
public class TempScheduler {    // .. scheduledexecutors service code to start the background thread    // call the service and get the data and then parse     // the response.    private void callServiceURL() {        String url = "url";        RestTemplate restTemplate = new RestTemplate();        String response = restTemplate.getForObject(url, String.class);        parseResponse(response);    }    // parse the response and store it in a variable    private void parseResponse(String response) {        //...               // get the block list of hostnames        Map<String, List<String>> coloExceptionList = gson.fromJson(response.split("blocklist=")[1], Map.class);        List<String> blockList = new ArrayList<String>();        for(Map.Entry<String, List<String>> entry : coloExceptionList.entrySet()) {            for(String hosts : entry.getValue()) {                blockList.add(hosts);            }        }        // store the block list of hostnames which I am not supposed to make a call        ClientData.replaceBlockedHosts(blockList);    }}

Below is my ClientData class. replaceBlockedHosts method will only be called by a background thread meaning only one writer. But isHostBlocked method will be called by main application threads multiple times to check whether a particular hostname is blocked or not. And also blockHost method will be called from catch block multiple times to add the down host in the blockedHosts list so I need to make sure all the read threads can see the consistent data and are not making calls to that down host, instead they are making calls to next host in the hostnames linked list.

ClientData
public class ClientData {    // .. some other variables here which in turn used to decide the  list of hostnames    private static final AtomicReference<ConcurrentHashMap<String, String>> blockedHosts =             new AtomicReference<ConcurrentHashMap<String, String>>(new ConcurrentHashMap<String, String>());    public static boolean isHostBlocked(String hostName) {        return blockedHosts.get().containsKey(hostName);    }    public static void blockHost(String hostName) {        blockedHosts.get().put(hostName, hostName);    }    public static void replaceBlockedHosts(List<String> hostNames) {        ConcurrentHashMap<String, String> newBlockedHosts = new ConcurrentHashMap<>();        for (String hostName : hostNames) {            newBlockedHosts.put(hostName, hostName);        }        blockedHosts.set(newBlockedHosts);    }}

And below is my main application thread code in which I have list of hostnames which I am supposed to make a call. If the hostname is null or in the block list category, then I won't make a call to that particular hostname and will try next hostname in the list.

@Overridepublic DataResponse call() {    List<String> hostnames = new LinkedList<String>();    // .. some separate code here to populate the hostnames list    // from ClientData class    for (String hostname : hostnames) {             // If host name is null or host name is in block list category, skip sending request to this host        if (hostname == null || ClientData.isHostBlocked(hostname)) {            continue;        }        try {            String url = generateURL(hostname);            response = restTemplate.getForObject(url, String.class);            break;        } catch (RestClientException ex) {            // add host to block list,             // Is this call fully atomic and thread safe for blockHost method             // in ClientData class?            ClientData.blockHost(hostname);        }    }}

I don't need to make a call to the hostname whenever it is down from the main thread. And my background thread gets these detail from one of my service as well, whenever any server is down, it will have the list of hostnames which are block hosts and whenever they are up, that list will get updated.

And also, whenever any RestClientException is being thrown, I will add that hostname in the blockedHosts concurrentmap since my background thread is running every 10 minutes so that map won't have this hostname until 10 minutes is done. And whenever this server came back up, my background will update this list automatically.

Is my above code for block list of hostnames is fully atomic and thread safe? Because what I want is - If hostA is down, then no other thread should make a call to hostA until the blocked host list is updated.


Viewing all articles
Browse latest Browse all 3

Latest Images

Trending Articles





Latest Images