> Am 16.07.2015 um 18:14 schrieb "p...@highoctane.be" <p...@highoctane.be>: > > > Le 16 juil. 2015 15:07, "Norbert Hartl" <norb...@hartl.name> a écrit : > > > > > >> Am 16.07.2015 um 12:59 schrieb p...@highoctane.be: > >> > >> One question about Mongo. > >> > >> How do you handle HA (High Availability) in Pharo? > >> > > I don't. > > > >> The current driver (MongoTalk) connects to one single mongod. > >> > >> I haven't seen any support for replicasets and identifying who is the > >> mongod to write to in MongoTalk (this support is built in any Python, > >> Ruby, ... driver they do provide, including sharding support and GridFS). > >> > > As far as I know there is no support for all of these. It would be really > > good to have them. But if nobody contributes it may be not needed after all. > > Working - slowly - on it. > Great! I'd like to see support for this. If you have anything commit it. Or ask. I'll be happy to assist.
Norbert > > > > >> Also, I've been experiencing a couple of protocol errors when working with > >> mongod under some scenarios (unrecognized command coming back in the wire > >> protocol). Looks like MongoTalk and mongod were out of sync on the wire > >> protocol. > >> > > You need to be careful because the mongo connection is a single stream > > aligned request by request. If another thread writes on the stream at the > > same time you will experience what you call "out of sync". > > Not such issue in the current code AFAIK but will look closer. > > > > > Norbert > > > >> Thanks and kudos for one more nice application! > >> > >> Phil > >> > >> > >> On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norb...@hartl.name> wrote: > >>> > >>> Hi Torsten, > >>> > >>> > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <asta...@gmx.de>: > >>> > > >>> > Another story from 2Denker is up: http://pharo.org/success/MultiCity > >>> > > >>> > Client seems to be done using Amber when I check the login page which > >>> > was > >>> > styled with Bootstrap. Server in Pharo with Nginx. I guess you use > >>> > Mongo as > >>> > DB (with Voyage or without). > >>> > > >>> > @Norbert/@Marcus: if possible can you share with us a few more > >>> > technical details about > >>> > the technologies/stack used. Also about size (LOC, users, nr of images) > >>> > and pitfalls ... > >>> > > >>> > There is always something one can learn from the experience of others. > >>> > >>> sure I can give some insight in the project. > >>> > >>> For the admin client we use amber plus bootstrap. The backend for this is > >>> a pharo image with voyage. As you can see in the screenshot there is a > >>> geo location entered. That can be searched afterwards because mongo > >>> provides geo spatial indexes. > >>> > >>> The project is built upon a service we provide at 2denker. The service is > >>> a registry for app installations, users and message tokens. We provide > >>> libraries for ios, android and windows mobile that registers the app, > >>> assigns a user, requests a message token from the user and stores it. The > >>> service is used for notifying the user at return of the car. You then get > >>> a notification containing the time and price of your car rental. > >>> > >>> The architecture of our infrastructure is event based. Meaning that e.g. > >>> the installation registration service sends events to a central event bus > >>> like image. This stores the events in elasticsearch and provides the > >>> ability to register for events. > >>> > >>> What we had to do for this project? We've built an image that on the one > >>> hand serves the request of the client admin interface. On the other hand > >>> it registers at the event server for a certain kind of event. This event > >>> is triggered by the car return and piggybacks the geo location where the > >>> car has been left. When such an event travels through our system the > >>> event server sees a match and calls the image. The image extracts the geo > >>> information and searches the database for available advertisements. If > >>> one is found and conditions are met an additional message is sent. > >>> > >>> That's roughly it. In the whole process there are 8 pharo images involved > >>> but 2 are for redundancy so it is 6 different images. The rest is a mongo > >>> database and an elasticsearch database. If you want to know anything more > >>> don't hesitate to ask. > >>> > >>> Norbert > >>> > >>> > >>> > >> > >
