On some machines we get a failure because of unordered and duplicated notifications.
There's one broadcaster that increments the notif sequence number at each new notification sent.
On the other side (other JVM, same host) we've 2 connectors using WS protocol. Each connector is notif listener, they've each one instance of the same listener class. That listener ensures that notif sequence number goes up and that there's no duplicates.
The notifications are pulled. A total of 10000 notifications are sent BUT the notification buffer size is set to 10. This is a corner case to create overflow conditions so that it triggers emission of specific NOTIFICATION_LOST.
The failure is seen from time to time on two machines, one running RedHat EL 3 and the other Windows XP Pro.
The issue looks fairly linked to timing because as soon as you add a tiny extra trace a loop of 100 tries doesn't allow to reproduce it.
Said Jeff, with pull mode the connector takes notifications as they're made available in the buffer. If they arrive duplicated and unordered it's because they're like that in the buffer; that's why I log that issue against the Event Service. Feel free to reassign it.
I will try to reproduce it with RMI but the connector's speed is so different I'm not sure it'll proove something; stay tune !
Got the same failure with RMI/IIOP (test stress_002) on Windows XP + JDK 7 b34.