Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
(for example)
you’d need something like the following:
image: docker:latest
…
stages:
- build
- test
build:
stage: build
services:
- docker:dind
script:
- # login etc …
- docker build --tag image-name:tag-test . --target test
- docker build --tag image-name:tag-publish . --target publish
- docker push image-name:tag-test
- docker push image-name:tag-publish
test:
stage: test
services:
- docker:dind
script:
- # login etc …
- docker pull image-name:tag-test
- docker run image-name:tag-test composer run test
analyse:
stage: test
services:
- docker:dind
script:
- # login etc …
- docker pull image-name:tag-test
- docker run image-name:tag-test composer run analyseOr maybe (depending on how your image store is configured) you can do the following:
test:
stage: test
image: image-name:tag-test
script:
- composer run test
analyse:
stage: test
image: image-name:tag-test
script:
- composer run analyse
one of my projections skipped another event, and I'm using the write lock strategy, so I guess the only possible reason here is that MySQL transactions are not 100% consistent :/
@fritz-gerneth did you have any skip with the write lock?
@danizord in a broader perspective I didn't see any skips. yet I am investigating a similar issue as you describe .. yet I assumed this to be an issue with the projection's code, not the projector missing events.. but your question made me re-think if this might be the same situation as you ask for.
on the original mysql question: that I don't know.. given the underlying issue was that write & read order were not the same on the initial issue across concurrent writers.. I see that might even be the case within a transaction (as I assume neither is an explicit decision but just how mysql works)..
on the original mysql question: that I don't know.. given the underlying issue was that write & read order were not the same on the initial issue across concurrent writers.. I see that might even be the case within a transaction (as I assume neither is an explicit decision but just how mysql works)..
does this only happen to you if you save multiple events within the same transaction?
(asking because this is happening for us - we're seeing this issue only on occassions when a writer adds multiple events in one transaction)
@Danielss89 have a look at https://github.com/prooph/event-sourcing/blob/master/src/Aggregate/AggregateRepository.php#L263 to see how to use the
MetadataMatcher to load events based on their version number & apply them
also, in that moment we didn't have multiple concurrent writers, so the write lock could not prevent it
@danizord yes that pretty much looks like it. I won't have time to look into this any time soon though. maybe you could have a look at the original issue prooph/pdo-event-store#189 and adapt the scripts to do multiple inserts wrapped in a transaction
unfortunately unless there's some magic mysql flag I would not know of any direct solution to this, besides gap detection on the read side (which is not much of an issue for new streams as long as write locks are enabled.. as there would be no natural gaps occuring)
running it with serializable transaction isolation for 24+ hours and no gaps so far :)
@danizord we might wanna change the setup slightly maybe.. so producer to produce events more in 'bursts' then frequent stream.. this should allow multiple consumers to be always at the newest event.. might simulate the situation better where projections are idle for a while and have to handle multiple events at the same time..
not really an expert on the details of mysql's isolation levels.. buy my understanding is that serializable transactions should not affect this.. repeatable-reads should be sufficient for this already
(e.g. so far we have no script to reproduce this error consitently.. even if this has not happend for 24hrs yet this might be coindicence, wrong scripts.. or actually a fix.. but we have no way of verification)
How do people handle infrastructure type exceptions during message bus dispatch? For example; a mysql gone away exception, by default in prooph/service-bus these are caught and added to the event. I see I can add a plugin to inspect exceptions as part of the finalise portion. I’m thinking I could then rethrow a wrapped exception there, is that the recommended approach?
I'm going to use prooph/improoph in my project
I just read a few article CQRS/ES of the project
I try to use it, the future could be used in a production environment
I found that Chinese there was no use it, perhaps it is difficult to understand， hahah :)
@m9rco Check the Event Engine: https://event-engine.io/ especially the tutorial! It uses prooph under the hood, but is much easier to start with.
