Yeah, the performance cost is why I only update the DB after a successful send, and then only with basic info, not all the different pkt type counts.
As for the eval{}, feel free to try it on the above code. What seems to happen (as per the results above) is that it can't handle repeated failures ie if MySQL doesn't come back quickly, it survives 1 or 2 DB related errors, but finally keels over, even if used with SIG{__DIE__}.
If you can prove me wrong I'd be ecstatic :-) .
I've also tried putting the eval around just the SQL cmd block ie from SELECT ... to ... finish, without success. | [reply] |
Yeah, the performance cost is why I only update the DB after a successful send, and then only with basic info, not all the different pkt type counts.
You could consider using a shared memory segment or mmap'd file for this sort of information; they're very fast, but the OS can provide persistence even if your process dies.
As for the eval{}, feel free to try it on the above code.
Well, the code below worked for me reliably over a few hundred connects...
| [reply]
[d/l]
[select] |
Thx for that; I tried a few eval combinations, but obviously missed something.
(Don't think I've ever had to use evals in the past)
Working on it now, as my actual code is more complex than my example OP. As I said, I was hoping to use a simple single die trap rather than lots eval{}s, but so long as it works I guess.
Cheers
Chris
| [reply] |