3 added 71 characters in body
source | link

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B. Edit to clarify, server A makes the requests concurrently using Futures.
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A. Edit: I just realized I could send the result in the JMS message, so no need for memcache at all.
  5. Server A can complete the DeferredResult after it gets the messages and readscollects all the resultsresponses from memcacheJMS.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMSJMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B. Edit to clarify, server A makes the requests concurrently using Futures.
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A
  5. Server A can complete the DeferredResult after it gets the messages and reads the results from memcache.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B. Edit to clarify, server A makes the requests concurrently using Futures.
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A. Edit: I just realized I could send the result in the JMS message, so no need for memcache at all.
  5. Server A can complete the DeferredResult after it collects all the responses from JMS.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

2 added 75 characters in body; edited tags
source | link

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B. Edit to clarify, server A makes the requests concurrently using Futures.
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A
  5. Server A can complete the DeferredResult after it gets the messages and reads the results from memcache.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A
  5. Server A can complete the DeferredResult after it gets the messages and reads the results from memcache.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B. Edit to clarify, server A makes the requests concurrently using Futures.
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A
  5. Server A can complete the DeferredResult after it gets the messages and reads the results from memcache.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.

1
source | link

Best approach for web service that calls other web services

The scenario is:

  1. client makes request to server A
  2. Server A makes potentially multiple requests to server B
  3. Server A blocks until all results return
  4. Server A collates responses into single response and returns to client

So currently the approach is the block using java Futures and return the results when they come in. My concern is this is quite thread intensive and I'm worried we will run out of resources on the server. I was thinking of going async in server A by using DeferredResult but since there is a thread for each request to server B, that doesn't seem to carry much benefit.

Alternatively, we could do

  1. Server A makes multiple requests to Server B
  2. Server B immediate returns a token for each request
  3. Server A tracks the tokens and returns DeferredResult
  4. Server B gets each result, puts it in memcache, sends a JMS message to server A
  5. Server A can complete the DeferredResult after it gets the messages and reads the results from memcache.

This has the advantage of being much much simpler in code (no complicated futures work) at the cost of being more complicated architecturally. It also introduces more layers (memcache and JMS) for failure. It also has the advantage of being much less resource intensive.

This is a high use system. Calls to system B can take anywhere from 1 to several seconds.