-
15. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 8:33 AM (in response to timfox)Ok, forget the comment about queues and wilcards, but the bottom line is allowable destinations are only used if checkAllowable = true.
-
16. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 6, 2009 8:37 AM (in response to timfox)We = ?
There is certainly no obligation in core that allowable destinations are always populated.
I meant JMSServerManager when it deploys a topic.Queues aren't created with wildcards, consumers are - so this makes no sense.
A queue is created with a wildcard and then a consumer consumes from this queue. This queue adds it's binding to any queue that matches its wild card. -
17. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 8:40 AM (in response to timfox)"ataylor" wrote:
We = ?
There is certainly no obligation in core that allowable destinations are always populated.
I meant JMSServerManager when it deploys a topic.
JMS server manager only exists in the JMS world. -
18. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 8:43 AM (in response to timfox)It's pretty simple: You're assuming allowable destinations are always populated, but that's not a valid assumption.
Currently your assumption only holds in JMS world. -
19. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 6, 2009 8:50 AM (in response to timfox)It's pretty simple: You're assuming allowable destinations are always populated, but that's not a valid assumption.
Currently your assumption only holds in JMS world.
Ok, so currently you're right, theres one scenario where there's a problem. If there no mapping and no allowable addresses for topic.a then a message routed to topic.a won't get routed to topic.*. At a core level can we not just specify that the destination always needs adding. Alternatively it means checking addresses during route which is a no no. -
20. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 8:57 AM (in response to timfox)"ataylor" wrote:
[ At a core level can we not just specify that the destination always needs adding.
Nope. We need to support the following semantics:
session.createQueue("myaddress", "myqueue");
session.sendMessage("myaddress", mymesage);
Having to add a "destination" is ugly and clumsy. It also makes it incompatible with AMQP. -
21. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 6, 2009 9:02 AM (in response to timfox)Nope. We need to support the following semantics:
session.createQueue("myaddress", "myqueue");
session.sendMessage("myaddress", mymesage);
Having to add a "destination" is ugly and clumsy. It also makes it incompatible with AMQP.
Ok so this means either creating all the possible combinations, which is how it works now.
Or checking for matching wildcard mappings on send, which will have an overhead. -
22. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 9:13 AM (in response to timfox)"ataylor" wrote:
Ok so this means either creating all the possible combinations, which is how it works now.
Or checking for matching wildcard mappings on send, which will have an overhead.
I'm not convinced those are the only two possibilities. -
23. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 11:20 AM (in response to timfox)How about a variation on the caching approach?
The old caching approach that we discounted involved evaluating the routing address against all wildcards once to get the matching list, then caching the list for subsequent lookups.
The problem with the approach was that if a new match was added you had to invalidate the cache, so the next lookup would re-evaluate all matches. If a lot of new queues were being added frequently (as is often the case), then this would cause a lot of re-evaluation and slowness.
We could be a bit cleverer, and not invalidate the entire cache very time a new wildcard queue is added, but just evaluate the new match and add it to the cache.
If a match is removed from the post office then we could just look in the cache for each routing address and remove it from there. -
24. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 6, 2009 2:25 PM (in response to timfox)So i guess this way, when a message is routed to an address that isn't in the cache we evaluate after that its in the cache for further use. Since typically you'll send many message to an address its one hit on the first message and then only if it didn't already exist in th efirst place.
-
25. Re: Algorithm broken in WildcardAddressManager
timfox Jan 6, 2009 3:52 PM (in response to timfox)Sounds about right
-
26. Re: Algorithm broken in WildcardAddressManager
timfox Jan 8, 2009 9:49 AM (in response to timfox)Here's a very simple test which causes the WildcardAddressManager to crash:
AddressManager am = new WildcardAddressManager(); Binding binding1 = new MyBinding(); am.addMapping(new SimpleString("a.b.c.d.e.f.g.h.i.j.k.l.m.n.*"), binding1); Bindings bindings = am.getBindings(new SimpleString("a.b.c")); assertTrue(bindings.getBindings().isEmpty());
-
27. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 8, 2009 10:01 AM (in response to timfox)ok, I'll sort it and add some more tests
-
28. Re: Algorithm broken in WildcardAddressManager
timfox Jan 8, 2009 10:59 AM (in response to timfox)Here's another basic test that fails
AddressManager am = new WildcardAddressManager(); Binding binding1 = new MyBinding(); am.addMapping(new SimpleString("a.b.*"), binding1); Bindings bindings = am.getBindings(new SimpleString("a.b.c")); assertTrue(bindings.getBindings().contains(binding1)); Binding binding2 = new MyBinding(); am.addMapping(new SimpleString("a.*"), binding2); bindings = am.getBindings(new SimpleString("a.b.c")); assertTrue(bindings.getBindings().contains(binding1)); assertTrue(bindings.getBindings().contains(binding2));
Looks like your test coverage is currently patchy. -
29. Re: Algorithm broken in WildcardAddressManager
ataylor Jan 8, 2009 11:20 AM (in response to timfox)thats what i would expect since a.b.c doesn't match a.*, change it to a.# and it works fine.