incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Fuseki: any issue which need to be closed before a release?
Date Mon, 12 Mar 2012 09:37:59 GMT
I had a look at the open issues related to Fuseki. Here is the list:

 - (major) (Rob, does this need to be included
in the first Fuseki release?)
 - (major) (... a patch from Alexander might
come for this)
 - (minor)
 - (minor)
 - (minor)
 - (minor)
 - (minor)
 - (minor)

Is any of this a blocker for a first release?

I am confused about JENA-220. Other than that, they all seems quite useful and reasonable.
Two are flagged as 'major' but I have not looked in details how much work is needed yet. They
don't seem to me to be 'blockers' for a release. What do you think?

JENA-201, even if flagged as minor, I think it's quite important if we want to successfully
allow Fuseki to be deployed and used in 'enterprisy' environments. In such places, you have
an app server or
a servlet container and that's it, no discussion, you need to use that (and therefore deploy
via standard .war which we know are well supported by all the app server and/or servlet containers
Fortunately!). Ok, it's not all places like this, but mostly... correct me if I am wrong.
I had a look at JENA-201 and Andy's proposal of a "single dispatcher to work on URI patterns"
seems, on paper, to be the best option. It allows us to take full control of requests dispatching
and it
minimizes, if not evict, any Jetty and/or other containers specific code. We just have our
config and configure the dispatcher via standard web.xml. A lot of web framework and/or libraries
which work
in a web app do this way. It makes sense. Don't get me wrong, I like Jetty and the unzip and
run approach. But we could (and should) support both scenarios: unzip and run as well as deploy
a war in a
servlet container.

I opened JENA-214 and had a look at how it could be implemented. However, considering JENA-201,
a solution depending on Jetty isn't the best option. A single dispatcher would allow us to
control read-only/read-write mode for datasets as well and make JENA-214 simple to implement
and portable across different servlet containers. The rationale behind JENA-214 is that this
management function is the minimum to enable all sort of things which are useful in production
environment. For example, one could easily deploy Fuseki on multiple machines in a master/slave
configuration (similar to what Apache Solr and many other solutions used to do): you have
one master which receive all your updates and as many slaves as you want to server your read
requests. You
achieve high-availability on the read path. The master is a single point of failures, if it
goes down you cannot update. There might be a time gap between an update and when the update
is available on
all the slaves (but many use cases can live with that). Replication can be done externally
to Fuseki, for example, using rsync. Backup is another very useful functionality and it is
now included in
Fuseki (kudos to Andy).

I'll have a look at JENA-201 and make some experiments to see how feasible the "single dispatcher"
is. There should not be much difference or implications in terms of performances right? Servlets
instantiated from a thread pool and so long no expensive objects are created on a per-request
basis a single dispatcher should be ok, right? Anyway, I'll come back this when I look (*)
at it more.


(*) 'looking' does not mean "assign the issue to me". I am not sure I have time for it and/or
I am best positioned to fix it with the best solution. But, I want to learn and understand
how it can be
done and I think it's important, therefore: I am looking into it. :-)

View raw message