<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Distributed-System on </title>
    <link>https://bzimmer.ziclix.com/tags/distributed-system/</link>
    <description>Recent content in Distributed-System on </description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sun, 21 Dec 2025 19:32:21 +0100</lastBuildDate>
    <atom:link href="https://bzimmer.ziclix.com/tags/distributed-system/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Been there -- a distributed ExecutorService.</title>
      <link>https://bzimmer.ziclix.com/2008/09/17/been-there-a-distributed-executorservice/</link>
      <pubDate>Wed, 17 Sep 2008 00:00:00 +0000</pubDate>
      <guid>https://bzimmer.ziclix.com/2008/09/17/been-there-a-distributed-executorservice/</guid>
      <description>&lt;p&gt;I happened to run across a new open-source project today I had not previously heard about: &lt;a href=&#34;http://www.hazelcast.com/&#34;&gt;Hazelcast&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;What really piqued my interest was the implementation of a distributed &lt;code&gt;ExecutorService&lt;/code&gt; as I wrote something of similar functionality to façade &lt;a href=&#34;http://www.orbitz.com/&#34;&gt;Orbitz&amp;rsquo;s&lt;/a&gt; Jini infrastructure. The design and implementation solved a couple primary objectives:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;add timeouts to Jini which is unfortunately lacking such a feature&lt;/li&gt;&#xA;&lt;li&gt;bound the number of concurrent requests being processed&lt;/li&gt;&#xA;&lt;li&gt;bound the number of threads created for request processing&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;The design was elegant, imo, because the exact same code worked either client or service-side &amp;ndash; it just mattered which way you twisted your head &amp;ndash; and masked the complexities of both Jini and the &lt;code&gt;ExecutorService&lt;/code&gt;. The timeouts were managed via the &lt;code&gt;Future&lt;/code&gt; and the throttling of requests and threads by configuring the backing &lt;code&gt;Queue&lt;/code&gt; and pool size. Spring wiring entirely hid the remote invocation machinery from the caller. In almost every case there were no code changes and the timeout and throttling features could be turned on and tuned entirely through a configuration change.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
