Michael Fowler wrote:
Unfortunately, we seem to be hitting a wall in terms of packets transmitted to the vendor. It is my understanding that the detail reader is serial in nature, meaning it only sends one packet to the vendor (in this case), and will not send another until it gets a response. The vendor is over a slow link, or the packets are otherwise delayed, so we are getting a backlog of detail entries. The detail file is filling faster than it can be flushed to the vendor.
Yes, that is a bit of an issue.
My question is, how can we fix this?
Hack the code. :(
A few ideas have been batted around. One is to write some code (via rlm_perl or rlm_python) that essentially does what the entire writer/reader combination is doing, only in parallel. Meaning, it handles transmitting and retransmitting to the vendor. In the short term this might be viable, but it's reinventing wheels, and it's hard to justify long-term given most of the people dealing with this are not programmers.
Too much work.
Another was to somehow load-balance the readers. I cannot find a configuration example to support this, but would it be possible, and more importantly useful, to have multiple readers pointing to the same detail file?
Fix the reader to handle more than one packet. The issue right now is that it only tracks where it is in the "detail" file in memory. It *could* have an auxiliary file giving: - packet offset - packet data (received response, last sent data, etc.) This should be tracked automatically, and cleaned up when the detail file is deleted. There are a number of corner cases to deal with (files getting out of sync, etc.), but it's possible. Alan DeKok.