Jonathan Oliver

It’s been a little while in coming, but nonetheless, I’m pleased to release the latest version of the CQRS EventStore  As always, you can find the source code on GitHub as well as the official pre-built binaries.  You can also find the EventStore package on the NuGet Gallery.  NuGet is the recommended way to install.

New in the release (since the v3.0 beta release)

• Fixes in the SQL implementation that could cause concurrency exceptions when running multiple instances of the EventStore against a single backend storage.
• Better SQL paging support when working with large data sets.
• Added a CommittedHeaders property to stream to help determine which “aggregate type” created the stream.
• Pointing to the latest versions of RavenDB, Mongo, MySql Connector, Json.NET, and ServiceStack.
• Added full logging across the library.  Various logging implementations are supported including log4net and NLog.
• Added the ability to “upconvert” events as they are loaded from persistence.
• Added ability to share IDbConnection across multiple operations on a single thread using a “ConnectionScope” to avoid 2PC promotion when using TransactionScope.

Looking forward:

• .NET 4.0 only.  Sorry for those still using .NET 3.5 (CLR 2), it’s time to upgrade.
• As with most open source libraries, the docs are deficient.  Part of the next release is to get a few GitHub wiki pages going along with some good code examples.
• As mention in the 3.0 beta post, the essence and spirit of the CommonDomain project will be merged into the EventStore.
• More storage engine support will be forthcoming.
• Two areas that need a little bit of attention are the API surrounding snapshots as well as the concept of “GetFrom(DateTime start)”.  I’ll be looking at doing something more like “GetFrom(int index)” in the near future.

The official release for EventStore 3.0 is just around the corner.  Following SemVer semantics, this is now version 3.0 instead of 2.1 or whatever.  his post is to highlight the differences between 2.0 and 3.0.  First and foremost, the packages are available for download here in both .NET 3.5 and .NET 4.0 flavors:

https://github.com/joliver/EventStore/downloads (contains all binaries and plugins for various persistence and serialization methods)

On NuGet, the following packages have been pushed.  Because this is a beta, not all of them are marked as “recommended” yet.

http://nuget.org/List/Packages/EventStore
http://nuget.org/List/Packages/EventStore.Logging.NLog
http://nuget.org/List/Packages/EventStore.Logging.Log4Net
http://nuget.org/List/Packages/EventStore.Serialization.Json
http://nuget.org/List/Packages/EventStore.Serialization.ServiceStack
http://nuget.org/List/Packages/EventStore.Persistence.RavenPersistence
http://nuget.org/List/Packages/EventStore.Persistence.MongoPersistence

Big Changes

• Paging: The SQL and Raven implementations now support paging automagically.  This is to help facilitate queries where large result sets could potentially be returned, e.g. an stream with hundreds or thousands of commits against it or returning all commits since a given point in time.  Page size is configurable with sensible defaults.  Mongo already supports paging under the hood automatically.
• Two-phase commit: Perhaps the biggest new feature is support for 2PC.  Because *so* many people asked for it, here it is.  There are a few big, fat issues to be aware of.  First and foremost, your storage engine must support 2PC.  That pretty much means SQL Server and Raven.  One issue with Raven is that you get one operation per 2PC.  This is due to the way Raven handles 2PC and doesn’t update its indexes on commits until *after* the full transaction completes.  In other words, you can’t query and get the stuff you just saved until after the transaction is complete.
• Most all dependencies are now automatically resolved from the NuGet gallery *at compile time*.
• The two message “dispatchers”—sync and async—are now called ‘”dispatch schedulers”, therefore the interface IDispatchCommits is now IScheduleDispatches.  The associated IPublishMessages (which never felt like a good fit), is now called IDispatchCommits.  The associated implementations have changed accordingly.
• Added logging throughout the library.  There’s a little bit left to do for logging in Raven and Mongo, but all activities can now be logged.  You can output the diagnostic messages to the console, trace window, log4net, or NLog.  This can be specified using the “LogTo” wireup overload.
• Added “SystemTime” abstraction to facilitate testing.
• Added support to publish packages to NuGet.
• For those using MySQL, I added an index that was missing—you may want to run this to add the index: CREATE INDEX IX_Commits_Stamp ON Commits (CommitStamp);
• The SQL implementation will now throw a “StorageUnavailableException” if storage is offline.
• A few of the interfaces and implementations surrounding SQL persistence have changed—this should only really affect you if you’re doing a custom SQL dialect.
• Raven can now be run be run in Azure without a config file.
• Fixed a few outstanding issues that had built up in the GitHub issue tracker.

Once this release solidifies, I’ll turn my attention to 3.1 (hopefully it’ll be a point release).  There are some exciting things coming in 3.1 and beyond:

• Merging in the "essence” of CommonDomain (which was spike code that worked a little too well) into EventStore but with a slightly different model that doesn’t violate the spirit and ultimate purpose of either library.
• Support for Amazon (SimpleDB/S3)
• Support for Windows Azure (Tables/Blobs)
• Support for CouchDB
• Support for Cassandra
• Support for Redis
• Support for Oracle
• Support for Sybase
• Support for a local, file system-based store.
• Support for Protocol Buffers and other serialization formats.

In the near future, perhaps after this release or one of the next ones, I will be dropping support for .NET 3.5 entirely.  There is a point at which I can’t hold this library back any longer from taking advantage of .NET 4.0-specific features.  I don’t expect any big showstoppers with this beta release.  Once I address any feedback I get and have used this in production on my own systems long enough, I plan to push a release by around the first or second week of October.

For the past six years, I’ve been using a VOIP-based telephone service called Vonage.  In many regards, everything with them has been stellar—from call quality, to service availability, to price.  As my household needs have changed, I have found that my family’s usage of Vonage has decreased significantly—almost to the point where we could eliminate our home telephone altogether.  For various strategic reasons as well as to provide a level of redundancy in case of cellular outages or other unexpected events, we decided to keep a landline.  The hard part about Vonage was that it was hard to justify the cost as compared to our usage.  So off I went in search of an alternative solution.

I had heard a lot about Ooma—especially how inexpensive it was which was very appealing because our needs were so minimal.  So on June 11th, I decided to take the leap and move to Ooma and I ordered the device on Amazon.com because it was $50 cheaper than through Ooma’s web store.  A few days later it arrived (gotta love Amazon Prime).  I plugged it in and set it up and within a few minutes I had a dial tone.  After doing a few tests over the following days, I decided to port my telephone number to Ooma.  Within a short time that was complete and everything was great.  Until it wasn’t.

On July 17, my Ooma device died.  Wouldn’t boot.  Nothing.  And that’s when the problems started.  From a technical side, it’s no big deal—just contact Ooma and have them send out another device which I did.  After contacting support, I got a response via email on July 21 asking me to confirm my shipping address so they could send a new device.  Okay, no big deal.  My family was on vacation for the next week and when I got home I expected a package to be waiting for me.  Except it wasn’t.

During this time all calls to the home phone were forwarded to my wife’s cell.  The latency was worse than abysmal.  It was literally a five-second lag which rendered conversations virtually impossible.

I finally called Ooma on July 28 to see what was happening.  They said they’d send a unit out as soon as possible.  It arrived on August 2.  It was then that I discovered that the power brick for the first one was bad—not the original device itself. The new device worked fine and I boxed up the original one and got it ready to send back.  The next day I received another Ooma device in the mail.  Weird.  I only asked for one.  Apparently they sent two because I had contacted them twice and they were somehow logged under different issues even though I provided an issue tracking number.

At this point my wife and I had a serious conversation about Ooma.  We had had enough.  The service, when it was working, was good enough, but it was totally useless during any internet/service outage because the cell phone delay was horrible.  Compounding the fact that it took about two weeks to get a new device to us—that’s worse than ridiculous.  On the flip side with Vonage, during any kind of internet outage when calls were forwarded to my wife’s cell she couldn’t tell that people didn’t just call her cell directly because there was no perceived latency.

About August 3, I called to cancel the service and to get a refund for the Ooma-brand device I purchased from Amazon.  I was informed that I would be unable to do so because the device was purchased through Amazon and I would need to seek a refund from them.  Amazon’s policy was 30 days so that wasn’t an option.   Furthermore, Amazon wasn’t the “at-fault” party in this.  Interestingly enough, Amazon also states that the serial numbers on the returns must match those shipped otherwise no refund would be issued.  Had I sent my original device back to Ooma, I’d be even more up a creek without a paddle.  The rep informed me that someone higher up would have to make the decision.  My wife received a phone call a few days later informing her that no refund would be issued and that we’d have to take the complaint up with Amazon.  #Epic Fail.

On August 11, I called again.  After explaining the entire situation again to another rep from their outsourced India-based telephone support, I was informed that someone else would contact me to discuss the matter further.  It’s been five days and I haven’t heard anything back from them.

Oh, and the phone has been unavailable since August 11 as well.  I sent back the replacement devices because the original device was actually working properly (with a new power brick).  I contacted them to re-associate the original device with the account and that was an exercise in pure frustration.  The complete and utter incompetence and inability of their support to do the most simple things beyond updating your email is astounding.  To date I have probably wasted upwards of seven hours on the telephone with them, which far outweighs any potential benefit the service was supposed to offer in cost savings.  I consider the small investment of time in this blog post to be a  public service to help those considering Ooma to make an informed decision.

I guess my beef with Ooma is four fold:

1. The customer “service” is by far the worst I have ever experienced.  AT&T, Comcast, Qwest, and the IRS are an absolute delight by comparison.
2. The investment of time it takes to resolve even the most simple of issues (like getting the device associated with your account) is astronomical and obliterates any potential cost benefits as compared to traditional PSTN or VOIP-based services.
3. When the internet is unavailable, the latency and delay experienced when the calls fails over to a cell phone makes the conversing impossible—thus defeating the purpose of a telephone altogether.
4. Ooma’s unwilling to budge on the idea of taking back a device they manufactured.

The last point deserves a bit of clarification.  With literally any other manufacturer or provider, it doesn’t matter the retail establishment through which a product was purchased, they will refund your money if you request it.  Oftentimes, a manufacturer will even have a 110% guarantee where they will refund more than the purchase price.  Ooma can’t seem to get this concept through their heads.  It’s almost as though they’ve disassociated themselves from the product they sell.  Ironically, they’re fully willing to send a replacement device when one fails, but when push comes to shove and a refund is requested, you’ve got to go through the original retail outlet.  As a manufacturer, I would expect them to stand behind their service and device regardless of where it was purchased—provided you can show proof of purchase.

In conclusion, I cannot recommend other telephone providers more highly compared to Ooma.  Every point of contact an interaction with them has been so excruciating and painful—such an epic fail—I am absolutely amazed they still exist.  Run away as fast as you can.  I’d go back to Vonage in a heartbeat.  And if you’re listening Ooma, which I doubt you are, you may want to start paying attention to Twitter.  There’s a good amount of chatter under the #ooma hashtag that you should be responding to.

My current plain is to actually run Asterisk on my Linux-based micro server at home and to use Vitelity or another SIP provider.  For those of you that have read to this point and that still have a home phone, what provider do you use?