> 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. > 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". Norbert > Thanks and kudos for one more nice application! > > Phil > > > On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norb...@hartl.name > <mailto:norb...@hartl.name>> wrote: > Hi Torsten, > > > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <asta...@gmx.de > > <mailto:asta...@gmx.de>>: > > > > Another story from 2Denker is up: http://pharo.org/success/MultiCity > > <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 > > > >
