Three test files below. First the publisher
And then a couple of files for the subscriber.
Tx++
import org.zeromq.ZMQ;
import java.nio.*;
import java.io.*;
import java.util.*;
class TestPub
{
public static void main (String [] args) throws InterruptedException
{
ZMQ.Context ctx = ZMQ.context (1);
ZMQ.Socket p = ctx.socket (ZMQ.PUB);
p.bind (bindTo);
Thread.sleep(4000);
byte topic [] = "order".getBytes();
byte data [] = "DZZDZDDDDDD".getBytes();
for (int i = 0; i != 2; i ++) {
p.send (topic, ZMQ.SNDMORE);
p.send (data, 0);
}
Thread.sleep(100000);
}
}
import org.zeromq.ZMQ;
import org.zeromq.ZMQ.Context;
import org.zeromq.ZMQ.Socket;
class TestSub implements ZeroMQConnectCallback {
public void methodToCallBack() {
System.out.println("I got the message");
}
public static void main(String[] args) throws InterruptedException {
ZeroMQ zeromq = new ZeroMQ();
Thread mcastThread = new Thread(new ZeroMQ.Mcast());
mcastThread.setDaemon(true);
mcastThread.start();
Thread.sleep(1000000);
}
}
import org.zeromq.ZMQ;
import org.zeromq.ZMQ.Context;
import org.zeromq.ZMQ.Socket;
class ZeroMQ {
public static ZMQ.Socket s;
static class Mcast extends Thread {
public void run() {
ZMQ.Context ctx = ZMQ.context (1);
ZMQ.Socket s = ctx.socket (ZMQ.SUB);
s.connect (connectTo);
s.subscribe(new byte[0]);
//byte topic [] = "order".getBytes();
//s.subscribe(topic);
while (true)) {
// Read envelope with address
String address = new String(s.recv(0));
String contents = new String(s.recv(0));
}
}
}
}
From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua Foster
Sent: Wednesday, March 21, 2012 3:51 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] PUB SUB in zmq 2.1.11
ZMQ should never lose a frame in the message. That would be considered a bug. I
have never seen it with 2.1.11. There are open bugs related to 3.1.x for this.
Can you create a simple test case that demonstrates the issue?
Joshua
On Mar 21, 2012, at 3:37 PM, Doherty, Kevin wrote:
So the scenario is this I think
The SUB subscribes to say "order"
The pub does a pair of sends as shown.
p.send (topic, ZMQ.SNDMORE);
p.send (data, 0);
The SUB which is doing a pair of recv(0)s, one for the "order" in the topic
header of the two part message
and a second for the data, entirely misses the first message sent.
Now if the subscription is for 'everything"
Ie.an empty byte, the behavior is a bit different.
The header (first part) is "lost" and then all subsequent "parts" are received.
This throws things off thereafter of course by the amount of the one "missed"
part.
As opposed to the entire first message when there is an actual subscription
filter string.
tx
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]>
On Behalf Of Joshua Foster
Sent: Wednesday, March 21, 2012 9:29 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] PUB SUB in zmq 2.1.11
I suspect this is caused by the time required to try reconnecting (it gets
progressively longer). Don't put a sleep between the connect and bind, just
before the sending first message.
Joshua
On Mar 21, 2012, at 6:56 AM, Doherty, Kevin wrote:
Folks,
I'm new to the mail list. Has there been any report of an issue with
zmq 2.1.11 where the first message
is lost in a pub-sub arrangement *but* Not because of the slow subscriber.
Ie.
when I send my first message it seems to not get delivered Despite a *very*
long delay between the following steps.
connect in the sub - bind in the pub - send first message from the pub
Same issue if I
Bind in pub - connect in sub - send first message from pub
With long delays between all of the above ?
Tx++
________________________________
The information contained in this communication is confidential and may contain
information that is privileged or exempt from disclosure under applicable law.
If you are not a named addressee, please notify the sender immediately and
delete this email from your system. If you have received this communication,
and are not a named recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
________________________________
_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
________________________________
The information contained in this communication is confidential and may contain
information that is privileged or exempt from disclosure under applicable law.
If you are not a named addressee, please notify the sender immediately and
delete this email from your system. If you have received this communication,
and are not a named recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
________________________________
_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
######################################################################
The information contained in this communication is confidential and
may contain information that is privileged or exempt from disclosure
under applicable law. If you are not a named addressee, please notify
the sender immediately and delete this email from your system.
If you have received this communication, and are not a named
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
######################################################################
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
