I've just prototyped a similar solution whereby the query is produced to a 
Kafka topic and the results are produced to another Kafka topic. The queries 
are process heavy and result light. Some of the results require post processing 
so this can be handled before the clients get the data.
We're running Kafka in k8s with Zookeeper and a prototype of Mosaic to handle 
concurrent writes.
I'm aiming to release a new version of Mosaic based on this work with docker 
and k8s setup.
-------- Original message --------From: Claude Warren <cla...@xenei.com> Date: 
10/08/2018  16:52  (GMT+00:00) To: users@jena.apache.org Subject: Re: Push 
I was actualy thinking of putting a message on a queue so that anyone
listening could pick it up.  Most of our infrastructure is based on push
rather than pull.  Particularly when our data sources are in a more secure
zone.  We only want to connect from the most secure zone to the lesser
secured zone not visa-versa  if possible.  A push would make much of this

worst case I can create a poller that does the push but I suppose I was
looking for a more elegant solution.


On Fri, Aug 10, 2018 at 1:28 PM, Andy Seaborne <a...@apache.org> wrote:

> General comment about Fuseki (or any server really):
> Having server track the clients so it can initiate sending is a real pain
> to do: clients go away, client crash without signing off, clients get
> moved, clients go slow, etc etc.
> Having the client poll the server may seem like excessive work but the
> reality is that many systems are built that way underneath for all those
> client reasons.
> The trick is to make the "ping" cheap.
> For RDF, keep triple with the tiemstamp of last change and get it each
> time.
> Or to put it another way, do Last-Modified or ETags for the data.
>     Andy
> On 09/08/18 17:29, Nouwt, B. (Barry) wrote:
>> Hi Claude, another hack that might work (but is probably a bit devious),
>> is using a GenericRuleReasoner rule instead of a ASK query, like:
>> [myAskRule: (?some pre:pattern bla:Eek) (?some eek:prop
>> "1234"^^xsd:integer) (...) -> print("The condition is TRUE!!!")
>> customBuiltinThatNotifies(?some, "s...@eek.org") ]
>> Note that you would need to create a custom 'notification' Builtin that
>> contains the actual notification logic.
>> Regards, Barry
>> -----Original Message-----
>> From: ajs6f <aj...@apache.org>
>> Sent: donderdag 9 augustus 2018 16:59
>> To: users@jena.apache.org
>> Subject: Re: Push notification?
>> Hey, Claude--
>> Is it a particular ASK query or just any time any ASK query returns
>> successfully? I don't know enough about ARQ to really answer your question,
>> but a hack might be to see if there is an exact pattern of calls to find()
>> that occur for that ASK and only that ASK on the underlying DatasetGraph
>> and use DatasetGraphWrapper to intercept and fire your notifications. I'm
>> guessing there's a much cleaner better way to do that at ARQ, which will
>> actually know about ASK queries, and I'm looking forward to someone who
>> knows more than I telling us what that is. :grin:
>> ajs6f
>> On Aug 9, 2018, at 10:39 AM, Claude Warren <cla...@xenei.com> wrote:
>>> Does anyone have a way to have Jena/Fuseki perform push notifications?
>>> I am looking for a mechanism whereby I can create an ASK query and be
>>> notified when it succeeds.
>>> Any ideas would be appreciated.
>>> --
>>> I like: Like Like - The likeliest place on the web
>>> <http://like-like.xenei.com>
>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>> This message may contain information that is not intended for you. If you
>> are not the addressee or if this message was sent to you by mistake, you
>> are requested to inform the sender and delete the message. TNO accepts no
>> liability for the content of this e-mail, for the manner in which you use
>> it and for damage of any kind resulting from the risks inherent to the
>> electronic transmission of messages.

I like: Like Like - The likeliest place on the web
LinkedIn: http://www.linkedin.com/in/claudewarren

Reply via email to