Re: [zeromq-dev] ZeroMQ 4.2 release, planning
Kevin, this is really neat. :) On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill wrote: > On 9/05/16 21:45, Kevin Sapper wrote: >> >> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test > > > Thanks for automating this. It looks great. > > This gives us two downloads per release (each in .tar.gz and .zip): > > https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz > -- the Travis generated tarball (which I assume is prepared ready for > "./configure, make, make install") > > https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz > -- the GitHub auto-generated tarball from that release tag (which I assume > is what a git clone would give you, so a few extra steps required). > > So downloaders can choose the one they want. (Including .zip file > variations of both.) > > Also of note, both URLs include a filename at the end, so "wget" > automatically does the right thing with the downloaded files (I just > tested). > > Ewen > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZeroMQ 4.2 release, planning
On 9/05/16 21:45, Kevin Sapper wrote: [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test Thanks for automating this. It looks great. This gives us two downloads per release (each in .tar.gz and .zip): https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz -- the Travis generated tarball (which I assume is prepared ready for "./configure, make, make install") https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz -- the GitHub auto-generated tarball from that release tag (which I assume is what a git clone would give you, so a few extra steps required). So downloaders can choose the one they want. (Including .zip file variations of both.) Also of note, both URLs include a filename at the end, so "wget" automatically does the right thing with the downloaded files (I just tested). Ewen ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] PUB-SUB with asynchronous response
I'm not sure I fully understand the challange, anyway this is what I have in mind: Auction server that expose both PUB and ROUTER. Bidders connect to both. Bidder subscribe to relevant auction. When bidder want to mske a bid it sending message to the router which process the bid and publish it. What am I missing? On May 9, 2016 02:22, "Rajalakshmi Iyer" wrote: > Hello, > > I am working on an auction server which needs to forward each incoming > request to several bidding services and conduct an auction based on the > responses received from the bidders in real-time. > > One option is to employ asynchronous REQ-REP using ROUTER-DEALER against > each bidder for every incoming request. As the number of bidder types > increases, this option will cause the auction server to run out of sockets. > Also note that each bidder, is actually a group of auto-scaling bidder > instances behind a load balancer. Can ROUTER-DEALER work with a 3rd party > load balancer in between? > > Another option is to use PUB-SUB, where the incoming request is published > by the auction server and the bidders subscribe to the same, except the > bidders now need to respond with their bids. One could potentially employ a > cache to save the bids from all bidders and have the auction server query > this cache. But that means that the auction server needs to necessarily > wait for a max timeout before querying this cache, even though bidders > would have responded way before the timeout. > > Are there any established ZeroMQ patterns that aim to solve such cases? > Any advice is greatly appreciated. > > Thanks! > > > This email and any attachments to it may be confidential and are > intended solely for the use of the individual to whom it is addressed. Any > views or opinions expressed are solely those of the author and do not > necessarily represent those of Blis Ltd, a company registered in England > and Wales with registered number 06455773. Its registered office is 5th > Floor, 85 Tottenham Court Road, London, W1T 4TQ, United Kingdom. > > If you are not the intended recipient of this email, you must neither take > any action based upon its contents, nor copy or show it to anyone. Please > contact the sender if you believe you have received this email in error. > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZeroMQ 4.2 release, planning
The deployment has a couple of constraints (see .travis.yml -> deploy: on: ). One constraint is the repo MUST be "zeromq/libzmq". If we port this to zeromq4-x and zeromq4-1 we need to adjust this or remove this constraint altogether. 2016-05-09 13:04 GMT+02:00 Luca Boccassi : > Awesome, thanks! > > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to > push the tags corresponding to the last commit of each previous release, > right? It might make moving all downloadable to Github a much easier > process. > > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote: > > On libzmq master it's now possible to let travis automatically deploy > > artifacts. The deployment is triggered if a new tag is created. I've > > created a test release and tag[1] to see if it is working properly. The > > files that are available under this release have been deploy by travis. > > > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test > > > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi : > > > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote: > > > > Hi, > > > > > > > > Just for a curiosity - the content of packaging/debian collide with > > > > standard Debian packaging? It is intentionally there to not clash, so > > > maybe > > > > solve this problem. Either by not generating them, either by defying > > > safer > > > > location. > > > > > > It's not a problem with the location, it's just that the Debian source > > > package will end up having packaging stuff duplicated and with > different > > > content: 2 changelogs, 2 control files, etc. > > > > > > But again this is exactly why make dist exists - having that generated > > > packaging code in the repository is useful, no need to remove it. > > > > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote: > > > > > One note, 'make dist' always fails the first few times because > files > > > > > are missing. Keep this in mind. The git tarball has the great > > > > > advantage of never failing. (And since it makes tarballs look like > git > > > > > clones it gives the same experience to all developers.) > > > > > > > > > > I'd vote for killing 'make dist'. It also makes us dependent on > > > autotools. > > > > > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1, > > > > and ./autogen.sh; ./configure; make dist works just fine. > > > > It was broken a while ago, but I fixed it, and now the CI tests that > it > > > > works. > > > > > > > > Besides, IMHO there are 2 big problems with just tarring up the git > > > > repo. > > > > > > > > First of all, it doesn't remove the dependency, it just moves it > down to > > > > the user. Which means we'll start getting bug reports that are due to > > > > the different versions of autotools or cmake used (and there are a > lot! > > > > ). > > > > > > > > But most importantly, the tarball will ship stuff that shouldn't be > > > > shipped, which is a huge problem for distribution packagers. For > > > > example, in CZMQ, the packaging bit would be shipped. That would > break > > > > many things in the package build process, and the distro maintainer > (ie: > > > > me :-) ) would have to take the shipped tarball and sanitize it, > nuking > > > > all extraneous bits. This should not be necessary! That's exactly the > > > > reason "make dist" exists. > > > > > > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens > wrote: > > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi < > > > luca.bocca...@gmail.com> > > > > wrote: > > > > > > > > > > > >> Is any of the API I marked as draft actually ready for release? > > > > > > > > > > > > Even so, leave it 'draft' until it's actually being used. > Changing > > > > > > minds is expensive otherwise. > > > > > > > > > > > >> So should we use branches instead for bugfix releases? > > > > > > > > > > > > All fixes to master. In the extraordinary case where a bugfix > release > > > > > > cannot be made from master, a branch could work. We never needed > this > > > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely > recommend > > > > > > against branches unless it's the only option. (And I think we've > > > > > > designed ourselves space to never need that option.) > > > > > > > > > > > >> Isn't it possible to do the github release thing with the > result of > > > > > >> "make dist"? I think I've read somewhere that you can use the > > > result of > > > > > >> CI builds. > > > > > > > > > > > > Seems Kevin has solved this, almost :) > > > > > > > > > > > > -Pieter > > > > > ___ > > > > > zeromq-dev mailing list > > > > > zeromq-dev@lists.zeromq.org > > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > > > ___ > > > > zeromq-dev mailing list > > > > zeromq-dev@lists.zeromq.org > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > ___ > > > > zeromq-dev mailing
Re: [zeromq-dev] ZeroMQ 4.2 release, planning
Awesome, thanks! So now if we port this to zeromq4-x and zeromq4-1, we'll just have to push the tags corresponding to the last commit of each previous release, right? It might make moving all downloadable to Github a much easier process. On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote: > On libzmq master it's now possible to let travis automatically deploy > artifacts. The deployment is triggered if a new tag is created. I've > created a test release and tag[1] to see if it is working properly. The > files that are available under this release have been deploy by travis. > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi : > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote: > > > Hi, > > > > > > Just for a curiosity - the content of packaging/debian collide with > > > standard Debian packaging? It is intentionally there to not clash, so > > maybe > > > solve this problem. Either by not generating them, either by defying > > safer > > > location. > > > > It's not a problem with the location, it's just that the Debian source > > package will end up having packaging stuff duplicated and with different > > content: 2 changelogs, 2 control files, etc. > > > > But again this is exactly why make dist exists - having that generated > > packaging code in the repository is useful, no need to remove it. > > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote: > > > > One note, 'make dist' always fails the first few times because files > > > > are missing. Keep this in mind. The git tarball has the great > > > > advantage of never failing. (And since it makes tarballs look like git > > > > clones it gives the same experience to all developers.) > > > > > > > > I'd vote for killing 'make dist'. It also makes us dependent on > > autotools. > > > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1, > > > and ./autogen.sh; ./configure; make dist works just fine. > > > It was broken a while ago, but I fixed it, and now the CI tests that it > > > works. > > > > > > Besides, IMHO there are 2 big problems with just tarring up the git > > > repo. > > > > > > First of all, it doesn't remove the dependency, it just moves it down to > > > the user. Which means we'll start getting bug reports that are due to > > > the different versions of autotools or cmake used (and there are a lot! > > > ). > > > > > > But most importantly, the tarball will ship stuff that shouldn't be > > > shipped, which is a huge problem for distribution packagers. For > > > example, in CZMQ, the packaging bit would be shipped. That would break > > > many things in the package build process, and the distro maintainer (ie: > > > me :-) ) would have to take the shipped tarball and sanitize it, nuking > > > all extraneous bits. This should not be necessary! That's exactly the > > > reason "make dist" exists. > > > > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens wrote: > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi < > > luca.bocca...@gmail.com> > > > wrote: > > > > > > > > > >> Is any of the API I marked as draft actually ready for release? > > > > > > > > > > Even so, leave it 'draft' until it's actually being used. Changing > > > > > minds is expensive otherwise. > > > > > > > > > >> So should we use branches instead for bugfix releases? > > > > > > > > > > All fixes to master. In the extraordinary case where a bugfix release > > > > > cannot be made from master, a branch could work. We never needed this > > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend > > > > > against branches unless it's the only option. (And I think we've > > > > > designed ourselves space to never need that option.) > > > > > > > > > >> Isn't it possible to do the github release thing with the result of > > > > >> "make dist"? I think I've read somewhere that you can use the > > result of > > > > >> CI builds. > > > > > > > > > > Seems Kevin has solved this, almost :) > > > > > > > > > > -Pieter > > > > ___ > > > > zeromq-dev mailing list > > > > zeromq-dev@lists.zeromq.org > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > ___ > > > zeromq-dev mailing list > > > zeromq-dev@lists.zeromq.org > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > ___ > > > zeromq-dev mailing list > > > zeromq-dev@lists.zeromq.org > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > ___ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev signature.asc Description: This is a digitally signed message
Re: [zeromq-dev] ZeroMQ 4.2 release, planning
On libzmq master it's now possible to let travis automatically deploy artifacts. The deployment is triggered if a new tag is created. I've created a test release and tag[1] to see if it is working properly. The files that are available under this release have been deploy by travis. [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test 2016-05-04 11:34 GMT+02:00 Luca Boccassi : > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote: > > Hi, > > > > Just for a curiosity - the content of packaging/debian collide with > > standard Debian packaging? It is intentionally there to not clash, so > maybe > > solve this problem. Either by not generating them, either by defying > safer > > location. > > It's not a problem with the location, it's just that the Debian source > package will end up having packaging stuff duplicated and with different > content: 2 changelogs, 2 control files, etc. > > But again this is exactly why make dist exists - having that generated > packaging code in the repository is useful, no need to remove it. > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote: > > > One note, 'make dist' always fails the first few times because files > > > are missing. Keep this in mind. The git tarball has the great > > > advantage of never failing. (And since it makes tarballs look like git > > > clones it gives the same experience to all developers.) > > > > > > I'd vote for killing 'make dist'. It also makes us dependent on > autotools. > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1, > > and ./autogen.sh; ./configure; make dist works just fine. > > It was broken a while ago, but I fixed it, and now the CI tests that it > > works. > > > > Besides, IMHO there are 2 big problems with just tarring up the git > > repo. > > > > First of all, it doesn't remove the dependency, it just moves it down to > > the user. Which means we'll start getting bug reports that are due to > > the different versions of autotools or cmake used (and there are a lot! > > ). > > > > But most importantly, the tarball will ship stuff that shouldn't be > > shipped, which is a huge problem for distribution packagers. For > > example, in CZMQ, the packaging bit would be shipped. That would break > > many things in the package build process, and the distro maintainer (ie: > > me :-) ) would have to take the shipped tarball and sanitize it, nuking > > all extraneous bits. This should not be necessary! That's exactly the > > reason "make dist" exists. > > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens wrote: > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi < > luca.bocca...@gmail.com> > > wrote: > > > > > > > >> Is any of the API I marked as draft actually ready for release? > > > > > > > > Even so, leave it 'draft' until it's actually being used. Changing > > > > minds is expensive otherwise. > > > > > > > >> So should we use branches instead for bugfix releases? > > > > > > > > All fixes to master. In the extraordinary case where a bugfix release > > > > cannot be made from master, a branch could work. We never needed this > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend > > > > against branches unless it's the only option. (And I think we've > > > > designed ourselves space to never need that option.) > > > > > > > >> Isn't it possible to do the github release thing with the result of > > > >> "make dist"? I think I've read somewhere that you can use the > result of > > > >> CI builds. > > > > > > > > Seems Kevin has solved this, almost :) > > > > > > > > -Pieter > > > ___ > > > zeromq-dev mailing list > > > zeromq-dev@lists.zeromq.org > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > ___ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > ___ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Assertion failure when receiving
Thanks for your response, I found the issue. I stored some zmq::message_t
objects (C++ high-level binding) in a vector and it turns out I did some
wrong bounds checking:
if (my_vector.size() > 0) { // should be a 1
size_t size = my_vector[1].size(); // example, did some more complex
work
}
So that call to my_vector[1] created a new object that was not initialized
properly...
On 6 May 2016 at 18:01, Doron Somech wrote:
> it seems you didn't initialize the zmq_msg structure before calling the
> receive method.
>
> Make sure to call zmq_msg_init before receiving the message.
>
> On Fri, May 6, 2016 at 6:38 PM, Ale Strooisma <
> a.strooi...@student.utwente.nl> wrote:
>
>> Hi guys,
>>
>> when receiving a message I get this error/warning:
>>
>> Assertion failed: check () (msg.cpp:220)
>>
>> That is on the "unlikely" line of this bit:
>>
>> int zmq::msg_t::close ()
>> {
>> // Check the validity of the message.
>> if (unlikely (!check ())) {
>> errno = EFAULT;
>> return -1;
>> }
>> ...
>>
>>
>> I don't really know what I should be looking for here. Could somebody
>> give some hints?
>>
>>
>> Kind regards,
>> Ale Strooisma
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
