[Pharo-users] StampClient produce only and dealing with heartbeat

Holger Freyther holger at freyther.de
Wed May 18 10:10:09 EDT 2016


Dear Sven,

I started to use the StampClient and intend to use it to produce data but for heartbeat and other parts I need to read from the socket as well. I wonder about the best strategy to deal with it.

The naive approach.


[
   | event sendFrame |
   event := sharedQueue next.
   sendFrame := self newSendFrameTo: queueName
   sendFrame text: event convertToText.
   stampClient write: sendFrame.
] fork.


But now the StampClient enforces a non-zero hearbeat.. so I could write something like this

[
   | event sendFrame |
   event := sharedQueue nextWaitFor: stampClient timeout * 3.
   event isNil
      ifTrue: [stampClient writeHeartBeat]
      ifFalse: [self convertAndSendEvent: event].
] fork.


But now I face the issue (but maybe I had it before as well) that the server will itself send an empty frame as its heartbeat function and I need to read it. So I could write...

[
   event := sharedQueue...
   "try to read all pending events? How often to repeat it read everything??"
   stampClient readNextFrame.
   ...
] fork



Or to make it more involved? And create a reader and writer?

procConsume := [
    [stampClient runWith: [:msg | " do nothing " ]] ifCurtailed: [connectionClosed...handling].
] fork.

procProduce := [
   [
     | event sendFrame |
     event := sharedQueue next.
     sendFrame := self newSendFrameTo: queueName
     sendFrame text: event convertToText.
     stampClient write: sendFrame.
   ] ensure: [procConsume... do what exactly?
] fork.

So the last options seems to be the best. But how to deal with with re-connects? How to not have have "procConsume" write the heartbeat data in the middle of the produced event? After all 

How did you solve that? Is the problem space clear enough?


holger





More information about the Pharo-users mailing list