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. > >> 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 >>> >>> >>> >> >
