Can't seem to get the CHM help files to work?

May 5, 2015 at 1:52 PM
I copied both the files to a local disk - when I click on a topic it is empty???
May 5, 2015 at 3:35 PM
I've been meaning to update the documentation in any case, but first, have a look at the attached zip file. It contains the documentation in two forms (and by the way, they seem to have eliminated the .chw file, so you theoretically don't need it now). But it also has a script for installing the documentation files on your machine in the standard places. Try that.

Once this is resolved, I'll revise the standard online copy...

Zip file
May 5, 2015 at 4:47 PM
Thanks for the quick response.

This did not help - I still only have the Table of Contents on the left side with no content no matter what I click on.

I executed the Install_Documentation.bat file.

J.D. Hicks

Principle Architect
Cadillac Jack

We build Slot Machines

This is my corporate email here at Cadillac Jack.
[email removed]

May 5, 2015 at 4:53 PM
Strange, it works for me (even on a machine where I never tried this before). So let's guess that something about your browser is causing this.

Can you try with a different browser? In particular, try with IE if you happen to have it, even if you strongly prefer Chrome or FireFox.

I'm wondering if maybe this uses a kind of macros or some other feature that your browser happens to be blocking. For me, it looks like the documentation pages for Microsoft's .NET classes -- index on the left, details on the right...
May 5, 2015 at 4:56 PM
PS: Can't resist: I always thought of slots as being the ultimate loner kind of thing to do. So where does group communication come into the picture?
May 5, 2015 at 5:49 PM
In the class-2 market (Indian Gaming) the games area based on a simulated Bingo Ball Draw.
There is a server connected to all the games in the casino that delivers this ball draw.

Currently we have a single server that performs this activity.

This is no longer sustainable as we have grown to the point that a single server is no longer scalable or reliable.


I am tasked with creating a system that is scalable and reliable.
The ball draw is stateful and I will need to scale that state across multiple servers.


May 5, 2015 at 5:51 PM
The batch file is looking for an installer tool that is not on my system.

I will be away from this task for a few hours I have been asked to help others on the team debug a production problem.


May 5, 2015 at 6:16 PM
Yes, this is a very good match to the capabilities of the system. It should be easy to build a solution along those lines.
May 6, 2015 at 4:24 PM
Is there a easy/best way to get the id of the group leader?


May 6, 2015 at 5:09 PM
Edited May 6, 2015 at 5:09 PM
Yes, trivially. Given a group g, g.GetView() returns the view (identical in all members who do this), and g.GetView().members[0] would be the Isis.Address object for the leader. You can also call v.GetMyRank() or GetRankOf(); the leader would be the process with rank 0. Then if that leader fails or deliberately shuts down (MUCH faster to explicitly do so than to just fail and let Isis notice through timeout!) the process that had rank 1 becomes the new rank 0, etc. If you prefer event upcalls notifying you of the view, just attach a ViewHandler method to the group and we'll do an upcall on an Isis2 thread instantly when the membership changes.

So this is very useful and we do a lot with it. For example, if the leader was responsible for announcing the next Bingo number, the new leader can seamlessly take over with the next number. (You would probably have a hierarchy: the group might be a set of servers, maybe 10 or 15 of them, and then each server could be the “proxy” for some number of web clients – use WCF, for example, in authenticated mode since real money is involved). So these web clients (my guess is that you could reach 500 or 1000 per server) would use WCF/SOAP RPC calls into their proxy to learn the next Bingo ball and report that to your users, and the servers would internally let the leader pick the ball, and it would use g.Send() to tell them – this is FIFO (good enough with just one leader) and very fast. That would then get you to 10,000 or so Bingo players per game if you wanted to go that far on scaling.

The one caution is to time-align the ball announcement to the players explicitly in your code. I would build this, measure it carefully and graph the delays for those WCF calls finishing, using NTP to synchronize clocks. Humans can’t easily perceive skews below 35ms, but as you push towards 100ms skew is noticeable.

So you would generate a graph of how long it takes before you player browsers can see the new ball, and I bet you would find that in this architecture, with 10,000 players, the skew can vary from perhaps 1ms after the ball was drawn to perhaps 75ms or 150ms. Then I would program in a delay based on the synchronized clocks: “ball was drawn at 10:47.012.011. announce it at 10:47.012.161” and have the browsers count down to that time before they reveal that next bingo ball, to make it fair. That way a skeptic at the back of the room won’t see Sally Smith over on the left side of the room constantly getting her reveal earlier than Tim Jones over here on the left… Internally, her browser might well get the ball a bit earlier and perhaps even systematically so (hard to avoid those kinds of patterns of latency) but the hidden built-in countdown inside the browser would delay Sally's reveal by 143ms, while delaying Tim's by only 87ms. And of course if someone has very poor performance and gets the ball late, you just reveal it without actually pointing this out to anyone. Hopefully it wouldn't happen much if your original latency experiments are done carefully, and wouldn't be noticeable.

Notice that I'm not really recommending just using Isis2 across the full set of game-playing consoles. This isn't because it is impossible (with effort you can get the system to run with tens of thousands of group members), but it is VERY hard to pull off (the startup sequence generates high messaging load and you need to do all sorts of tricks when the application bootstraps). By having smaller groups this is way easier -- even a group of 100 is fine -- and then each server can handle lots of clients systems.

We have lots of experience with web browser interactions with Isis2 servers -- we use WCF or RESTful RPCs, and those work absolutely fine. Then the server ends up with threads dedicated to client requests and threads that deal with Isis2, and you arrive at the architecture outlined above. My students are doing something almost identical to this as homework 4 in my cloud computing class right now at Cornell!
May 6, 2015 at 7:37 PM
Wow - I never expected you to take so much time and effort on my behalf;

Thanks a ton,

May 6, 2015 at 8:16 PM
Edited May 6, 2015 at 8:18 PM
This is what I do for fun! In fact I wonder why more people don't ask questions... maybe embarrassed to ask, or they just give up without asking.
May 7, 2015 at 1:54 PM
Is there a way to limit the log files.

I'm using this code but still continue to get logs every time I start one of my test apps.
Environment.SetEnvironmentVariable("ISIS_MUTE", "true");


May 7, 2015 at 2:00 PM
If you don’t want them created at all, ISIS_LOGGED=false will do that. ISIS_MUTE won't print to the console but still generates the log files.

I normally just put those sorts of things into the bash startup script or the .bashrc file (export ISIS_LOGGED=false; export ISIS_MUTE=false;) But using SetEnvironmentVariable should work too. Or you can just reach into the library and say Isis.ISIS_LOGGED = false; in your code.

May 7, 2015 at 3:25 PM


May 7, 2015 at 3:45 PM
I have a new issue...

WARNING: Lost connection to the ORACLE: attempting to reconnect...
System shutdown: After Isis ORACLE member (7584) failed, this client was unable
to contact any other ORACLE member.

I'm testing on a three server farm and killed two of the applications.

What can I do to get the remaining single box to accept a single ORACLE is all there is?


May 7, 2015 at 3:59 PM
I figured it out. I had five instances running across three servers.

From the manual...
"If false, then if a failure causes the Oracle to drop from size N to a size that isn’t a majority of N (e.g. if N=5, 2 or smaller; if N=3, to size 1) "

I dropped down to less than 2 when N was 5.


May 7, 2015 at 6:56 PM
Edited May 7, 2015 at 7:59 PM
Right. If you run 3 server instances on one machine, then the machine crashes or is shut down, membership would drop from 5 to 2 and the system no longer has a quorum.

In fact things are worse: if the 3 run in VMs than each of those instances can be an ORACLE member. But if they just run as normal processes, then only the first one on that shared machine can get the correct port numbers to play the ORACLE role. As a result, you end up with an ORACLE group that has 3 members even though 5 instances of your application are active. Then you killed a process or two and the ORACLE drops from 3 to 1 member. This is not legal, so the 1 member dies (but muted since you set ISIS_MUTE and ISIS_LOGGED to false, so it won't print anything). The remaining 2 processes had a connection to each of the ORACLE members, but lost all of them, hence they are left high and dry and they also fail, throwing exceptions which you caught and printed.

If you set ISIS_IGNOREPARTITIONS=true, the server would keep running in this case, but with some risk of a partitioning problem if the network separated the group into two subgroups, both of which would be alive. Normally people do consider running that risk, but where money is involved, as in your system, you don't want that to be a way to attack the solution (e.g. you could get two inconsistent "draw sequences" if someone pulled a network plug at just the right moment). So for you, you want the ORACLE members on separate machines, and you want ISIS_IGNOREPARTITIONS=false (the default).

But those members can also be members of your application group, so they play all the normal application roles too. They just have these extra roles of helping do system membership management.
May 7, 2015 at 7:57 PM
Thanks again.