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
