Question on redis transport behavior

[henry74]

So I have successfully setup the redis-transport to pass messages to multiple services. I was under the impression that services would only care about messages which match their patterns, but I'm getting errors in services which do not match a redis message:

Error: Seneca/0.5.20/gw1q46mof1vd/1410211898209/-: No matching action pattern found for "{cmd=wikipedia,searchString=ruby}", and no default result provided (using a default$ property).

I imagine a service should just ignore messages which do not match patterns they care about. For example, if an echo service has:

seneca.add({
    cmd: 'echo'
}, echoMe)

It should ignore a { cmd: 'wikipedia' } or am I missing something? The issue is the erroring service is passing a response back on the queue and using the callback and thus preventing other services from potentially matching the pattern.

[henry74]

@rjrodger I switched to the beanstalk transport per your suggestion on Twitter and still receive the same error.

11:27:19 wikipedia.1      | 2014-09-17T16:27:19.707Z    82e2rrkrvvns/1410971158873/-    ERROR   plugin  beanstalk-transport -   ACT 2j8gopjcmkg2    act --- -   Seneca/0.5.20/82e2rrkrvvns/1410971158873/-: No matching action pattern found for "{cmd=mongoSave,searchString=ruby}", and no default result provided (using a default$ property).       {plugin={}} Error: Seneca/0.5.20/82e2rrkrvvns/1410971158873/-: No matching action pattern found for "{cmd=mongoSave,searchString=ruby}", and no default result provided (using a default$ property).

[rjrodger]

Hi Henry. OK I think I understand. We haven't hit this because we tend to namespace our messages, and then only listen on the primary namespace. For eg, role:foo,cmd:*

I'm going to add an option to 0.5.21 to explicitly control this, with the default being "warn" - see https://github.com/rjrodger/seneca/issues/74

[boxxxie]

it would be really nice to have your usage of seneca explained in a bit more detail. i don't see how broadcast only plugin makes sense? but, it must make sense for you because you made it.

judging by some other issues i've seen on other plugins, i'm not the only one who is getting confused.

[henry74]

EDIT: Sorry @boxxxie not sure if this was directed towards me or Rodger :-)

Sure, happy to oblige. If i'm building a micro-service architecture and using a queue as the transport mechanism, it would be useful to build services without having to worry about every message that could appear on the queue. Forcing services to be aware of all messages patterns on a queue seems to introduce unnecessary coupling.

One example of a broadcast use case is if Service A is requesting data from Service B and Service C is looking to log particular messages for audit purposes. Service A would drop a message on the queue and listen for a response (matching a particular pattern). Service B would pick it up because it matches the pattern it cares about. Service C would also pick it up because it matches it's pattern and log it for auditing purposes.

One of the benefits of using a queue over web services is you don't need to know who the end service - you just push a request to a queue and wait for a response. I thought that was the entire point of pattern matching. Otherwise if the producer service has to know about the consumer message - seems very similar to a point-to-point web service call.