<galderz> i have a CacheManager who's name is based around the ip address to which it bounds
<galderz> imagine that you start and bounds to localhost:1234
<galderz> that's the name that I see in the auto-discovery queue
<galderz> however, if I shutdown the manager and start it again, it has a diff name, localhost:3456
<galderz> but the auto discovery queue still shows the old name
<galderz> importing works fine, it seems to link up to localhost:3456 but the name is incorrectly displayed
<galderz> pilhuhn, this looks to me a bug in the auto-discovery queue
<galderz> it should figure out that the name is different
<pilhuhn> yeah - this is a know limitiation -- the AD queue should clean up
<galderz> how can I clean up the auto discovery queue?
<pilhuhn> It can't figure that out by itself, as the one 1234 may come back
<pilhuhn> but there should be a way to mark the 1234 one as "no longer needed"
<galderz> it's a pretty bad limitation, v confusing to the user
<pilhuhn> yes
<pilhuhn> I agree
<galderz> so, if I see it again, how can I at least get around it?
<galderz> i wanna show the ispn users the correct cache manager instance in the queue
<galderz> clean up the queue somehow?
<galderz> discard the AD queue?
<pilhuhn> you may try to import 1234 and then after this is done, go to resource hub and directly un-import it again
<pilhuhn> could you please write an RHQ jira ?
<galderz> i did that actually
<galderz> and then when i started a new cache manager, it would never appear in the queue!
<pilhuhn> ah cool :) ccrouch1 is surely listening :)
<galderz> that AD queue looks v fragile to me
<pilhuhn> the new manager may be just an issue of scan time - either initiate a manual autodiscovery or wait some time
<galderz> ok, i'll modify that too for the demo