1. The information in the urouter.log-Files is cryptic. Abbreviations are inconsistent (srvid - sid), and hard to understand. Numbers and time-counting. I\'ve got the feeling that the time-Information in the urouter-log is not very precise or in sync with the \"real time\". It is impossible to reconstruct a situation out of the log-files, e.g. Finding common entries between urouter-log and corresponding userver-log files. No common \"time-counting\". (we\'ve got lots of userver-logs). To grep or awk throught the log is nearly impossible. Information spreaded and line-breaks... makes it more difficult for an automatied analysis. And there is zero description in the helpfiles concerning the log-Information of the urouter. It can be cryptic, no problem, but it must be coherent, and \"easy to analyse\" (e.h. grep or awk). 2. UROUTMON. Just a nice idea. If I want to start the UROUTMON, just to get a view what happens, I sometimes (depend on the place where i work) get some license issues. I possibly can\'t consume a customer license-File just to have a look on the UROUTMON what is going on. To hack around is not always a good idea. For LIVE not useable! Please make the uroutmon \"license free\". It is a nice tool, but it shouldn\'t search or consume any licenses. 3. UST. We\'ve got on one urouter lots of uservers, with lots of different usts, because we need to communicate different databases and in different \"context\". Currently there are somewhat of 100 UST-entries in the urouter.asn. It is really horrible to maintain the list. It could be nice to define a kind of \"dynamic\" UST where I can tell, if the UST has a specific format then the parameters should follow that \"format\". Something like (e.g.) xxx-z-yyy userver.exe /asn=xxx.asn /maxidle=z /ini=yyy.ini /...whatever... BTW. We are generating the asn-File (for the application and userver!) dynamic, so that this kind of ruling the UST would fit perfectly in our concepts.

Use Case

1. If cusotmer is unhappy with the performance, I want to see what did happen on the urouter at that time. How many servers are opened, how many traffic. Can I follow up the \"Job\", the customer had his problem from the userver.log (which is well filled) up to the specific urouter-entry, and to see what happened around this actions? The only way to reproduce is to look in all the logs, and to filter the logs. 2. Same as 1. logged on on the customers machine, if uroutmon doesn\'t work, I have no time to experiment around to get it run. 3. Starting to go via urouter on 60 different databases in two different contexts I need at least 120 entries. + a debug variant = 240 entries. Type errors are typical. All UST-Entries in the asn looks verry similar.




Operating System

Not Applicable



2 thoughts on “urouter issues”

  1. Related with this (point 2)…
    A few years ago I had to give a talk about GUI modernization. What to do to take advantage of improvements in version 9. I thought was a good opportunity to modernize the urouter monitor. Tabex, grid, javascripts, pop up windows, dynamic tooltips … the complete set.

    The result is a product (UMO) that we offer to our customers and makes urouter monitor a tool you want to use. Very useful for monitoring ws/web/mobile.

    With interesting things like right-click… “close this userver” or “close all like this one”.

    More info and screenshots:


Leave a Reply