From: <Pau...@di...> - 2011-10-19 17:04:57
|
Hi Bob, I had previously included a buffer for the reason you describe. Let me describe the situation in more detail. During a continuous scan a large number of scan points (order 1000) are to sent from the server to all listeners in as fast a time as possible (1second). Currently scan points are buffered both Corba system and then the client. The result is that the memory usage of the server and client goes up considerable as the queue of messages builds up, but all messages do get through in sequence. However when the scan points are sent via a PV in the server, and monitored by the client, I find that not all points are delivered. Currently the data I send via caput is a ByteArray with the first byte being incremented by 1 between caputs; the byte array is being allocated afresh for each caput. On the client I simply report when the first byte of a sequence of messages is not in itself in sequence. Most of the time the number is seen to increase by 1 but then it will miss out 2 or 3. The size of the gap is not seen for small byte arrays (1-10K) sent at 10ms intervals but is seen with larger sizes (100k). For now I just want to understand why the data I read in the monitor event is not the data sent in the caput method. Is this not expected behaviour when monitoring a waveform? Apart from this odd behaviour I have successful managed to replace all Corba notification in GDA with PVAccess/PVData; but so far the data is simply a serialized Java object which may be of interest to those using Java in the GDA client but not for anyone else. Thanks Paul ___________________________________________________________ Paul Gibbons, pau...@di...<mailto:pau...@di...> Tel: +44 1235 778512 Data Acquisition Team Leader, http://www.diamond.ac.uk/ Diamond Light Source, Chilton, Didcot, Oxon, OX11 0DE, U.K. From: Dalesio, Leo [mailto:da...@bn...] Sent: 19 October 2011 09:41 To: Gibbons, Paul (DLSLtd,RAL,DIA); epi...@li... Subject: RE: Quality of delivery of subscribe-publisher system using pvaccess Is there a buffer between the application and the PVClient? For PVClients that we develop, there is always a cache of data coming back over the network to disconnect the performance of the application from the notifications coming back. A table with an update flag is typically put there. For GUIs, this is a good model. -----Original Message----- From: Pau...@di... [mailto:Pau...@di...] Sent: Tue 10/18/2011 5:41 AM To: epi...@li... Subject: Quality of delivery of subscribe-publisher system using pvaccess Hi, I am trying to replace Corba notification with PVAccess monitors. The following sequence works fine: 1. Server - create PV 2. Client - add monitor to PV 3. Server use put to change value of pv 4. Client - receives monitor event and extracts new value However if step 3 involves many puts to the pv in quick succession the client does receive every value for the pv - there are gaps. Can anything be done to improve delivery if the client is slow for a moment. Thanks Paul ___________________________________________________________ Paul Gibbons, pau...@di...<mailto:pau...@di...> Tel: +44 1235 778512 Data Acquisition Team Leader, http://www.diamond.ac.uk/ Diamond Light Source, Chilton, Didcot, Oxon, OX11 0DE, U.K. -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |