What version to use?

[Kevin]

Everything that I have read about hook.io make it sound amazing, but I am struggling to get it to work. With the current npm version (0.8.7-1) the hooks get stuck in a reconnect loop about 75% of the time when the first hook is killed and it appears that they never recover from loosing the first hook. I noticed that several blog posts make reference to version 0.8.6 so I installed it and it seems to work as advertised. It makes me a little uneasy knowing that an update was released with a bug that big. Am I doing something wrong or was 0.8.7 not supposed to be a usable release?

[Kevin]

I guess the other question that should be asked is if hook.io is intended to be production ready?

[Marak Squires]

hook.io follows http://semver.org/ versioning ( for the most part ).

5. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you find a problem, do your part and report it.  

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[Kevin]

That helps. Number 10 says that version with a dash (-) indicate a prerelease version but the npm release dates make it look like 0.8.7-1 is newer than 0.8.7. Which version is newer?

I used v0.8.6 in a system that provides realtime results for for a sporting event this last weekend. For the most part it worked well. It did break down and the hooks stopped communicated with each other at one point. If I restarted them individually they would each say that they were connected but messages sent by any of the hooks would not be received by any other hooks. I had to shutdown all of the hooks at the same time to get everything working again.

One of the hooks acts as a socket.io server. I think it may have hit the 10k messages per second limit because forever restarted it a few times. I am going to work on load balancing the clients to multiple socket.io servers and add a speedlimit. That should solve the socket.io problem but any ideas why this would have broken the connection between the hooks?

On Sunday, March 4, 2012 2:50:17 PM UTC-5, Marak Squires wrote:

hook.io follows http://semver.org/ versioning ( for the most part ).

5. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you find a problem, do your part and report it.  

[Marak Squires]

10. A pre-release version MAY be denoted by appending a dash

I use dash versions to indicate bug fixes for patch versions. 

0.8.7-1 is newer then 0.8.7. 

0.8.7-2 would be newer then 0.8.7-2. 

They all indicate the version is 0.8.7

The -N indicates a bug fix had to be applied as a direct result of the initial 0.8.7 release. 

If there was new functionality, or an unrelated bug fix, I would bump to 0.8.8.

As for your report, it's mostly useless to me. Without reproducible use-cases, unit tests, or application logs, there isn't much I can do. Sorry.

I think in future versions I'm going to disable the Paxos reconnection features by default. In most cases, you should just be able to start one top level master hook and use a process monitor to keep it up. All other hooks will just find it and connect.

-- 

Marak Squires

marak....@gmail.com

[Marak Squires]

Oops, meant to say:

0.8.7-2 would be newer then 0.8.7-1 

[Kevin]

That makes sense.

I did a little more testing and found that it has to do with the master hook crashing. It seems that when the master crashes/restarts the next hook gets promoted. This works fine, but when the new master crashes/restarts all of the other hooks crash/restart within a few seconds. After this all of the hooks appear to be connected but can not communicate with each other.

I think I will write something that functions more like you described with a master that is always the master and the clients just reconnect to it.

On Monday, March 5, 2012 10:41:00 AM UTC-5, Marak Squires wrote:

Oops, meant to say:

0.8.7-2 would be newer then 0.8.7-1 

On Mon, Mar 5, 2012 at 7:40 AM, Marak Squires wrote:

10. A pre-release version MAY be denoted by appending a dash

I use dash versions to indicate bug fixes for patch versions. 

0.8.7-1 is newer then 0.8.7. 

0.8.7-2 would be newer then 0.8.7-2. 

They all indicate the version is 0.8.7

The -N indicates a bug fix had to be applied as a direct result of the initial 0.8.7 release. 

If there was new functionality, or an unrelated bug fix, I would bump to 0.8.8.

As for your report, it's mostly useless to me. Without reproducible use-cases, unit tests, or application logs, there isn't much I can do. Sorry.

I think in future versions I'm going to disable the Paxos reconnection features by default. In most cases, you should just be able to start one top level master hook and use a process monitor to keep it up. All other hooks will just find it and connect.

On Monday, March 5, 2012 10:41:00 AM UTC-5, Marak Squires wrote:

Oops, meant to say:

0.8.7-2 would be newer then 0.8.7-1 

On Mon, Mar 5, 2012 at 7:40 AM, Marak Squires <marak....@gmail.com> wrote:

10. A pre-release version MAY be denoted by appending a dash

I use dash versions to indicate bug fixes for patch versions. 

0.8.7-1 is newer then 0.8.7. 

0.8.7-2 would be newer then 0.8.7-2. 

They all indicate the version is 0.8.7

The -N indicates a bug fix had to be applied as a direct result of the initial 0.8.7 release. 

If there was new functionality, or an unrelated bug fix, I would bump to 0.8.8.

As for your report, it's mostly useless to me. Without reproducible use-cases, unit tests, or application logs, there isn't much I can do. Sorry.

I think in future versions I'm going to disable the Paxos reconnection features by default. In most cases, you should just be able to start one top level master hook and use a process monitor to keep it up. All other hooks will just find it and connect.