<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Hashmaps on Brave New Geek</title><link>https://bravenewgeek.com/tag/hashmaps/</link><description>Recent content in Hashmaps on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 31 Dec 2016 14:14:00 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/hashmaps/index.xml" rel="self" type="application/rss+xml"/><item><title>Fast Topic Matching</title><link>https://bravenewgeek.com/fast-topic-matching/</link><pubDate>Wed, 28 Dec 2016 17:52:30 -0600</pubDate><guid>https://bravenewgeek.com/fast-topic-matching/</guid><description>&lt;p&gt;A common problem in messaging middleware is that of efficiently matching message topics with interested subscribers. For example, assume we have a set of subscribers, numbered 1 to 3:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Subscriber&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Match Request&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;forex.*&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;And we have a stream of messages, numbered 1 to N:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Message&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Topic&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;1&lt;/p&gt;
&lt;p&gt;forex.gbp&lt;/p&gt;
&lt;p&gt;2&lt;/p&gt;
&lt;p&gt;stock.nyse.ibm&lt;/p&gt;
&lt;p&gt;3&lt;/p&gt;
&lt;p&gt;stock.nyse.ge&lt;/p&gt;
&lt;p&gt;4&lt;/p&gt;
&lt;p&gt;forex.eur&lt;/p&gt;
&lt;p&gt;5&lt;/p&gt;
&lt;p&gt;forex.usd&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;N&lt;/p&gt;
&lt;p&gt;stock.nasdaq.msft&lt;/p&gt;
&lt;p&gt;We are then tasked with routing messages whose topics match the respective subscriber requests, where a “&lt;em&gt;*”&lt;/em&gt; wildcard matches any word. This is frequently a bottleneck for message-oriented middleware like ZeroMQ, RabbitMQ, ActiveMQ, TIBCO EMS, et al. Because of this, there are a number of &lt;a href="http://zeromq.org/whitepapers:message-matching"&gt;well-known&lt;/a&gt; &lt;a href="http://wso2.com/library/articles/2015/05/article-fast-topic-matching-algorithm-implementation-for-wso2-message-broker/"&gt;solutions&lt;/a&gt; &lt;a href="https://www.rabbitmq.com/blog/2010/09/14/very-fast-and-scalable-topic-routing-part-1/"&gt;to the problem&lt;/a&gt;. In this post, I’ll describe some of these solutions, as well as a novel one, and attempt to quantify them through benchmarking. As usual, the code is available &lt;a href="https://github.com/tylertreat/fast-topic-matching"&gt;on GitHub&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Solving the Referential Integrity Problem</title><link>https://bravenewgeek.com/solving-the-referential-integrity-problem/</link><pubDate>Sat, 01 Dec 2012 13:37:46 -0600</pubDate><guid>https://bravenewgeek.com/solving-the-referential-integrity-problem/</guid><description>&lt;p&gt;&lt;em&gt;“A man with a watch knows what time it is. A man with two watches is never sure.”&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I’ve been developing my open source Android framework, &lt;a href="http://code.google.com/p/infinitum-framework/"&gt;Infinitum&lt;/a&gt;, for the better part of 10 months now. It has brought about some really interesting problems that I’ve had to tackle, which is one of the many reasons I enjoy working on it so much.&lt;/p&gt;
&lt;h3 id="chicken-or-the-egg"&gt;Chicken or the Egg&lt;/h3&gt;
&lt;p&gt;Although it’s much more now, Infinitum began as an object-relational mapper which was loosely modeled after &lt;a href="http://www.hibernate.org/"&gt;Hibernate&lt;/a&gt;. One of the first major issues I faced while developing the ORM component was loading object graphs. To illustrate what I mean by this, suppose we’re developing some software for a department store. The domain model for this software might look something like this:&lt;/p&gt;</description></item></channel></rss>