Hi Nina, Vedrin, All,
    Thanks for the remarks. 

On Mon, 2011-04-11 at 19:09 +0300, Vedrin Jeliazkov wrote:

> Hi Pantelis,
> 
> I've adjusted the SmokePing probes to monitor your latest deployment
> on port 8080:
> 
> http://ambit.uni-plovdiv.bg/cgi-bin/smokeping.cgi?target=NTUA


It's useful to have smokeping running on services. After a few days it
would be interesting to see how jaqpot3 performs under a heavier load.
JavaMelody mounted on http://opentox.ntua.gr:8080/monitoring is also
very useful for debugging!

> 
> I've noticed some issues though:
> 
> 1) curl -X GET -H Accept:text/uri-list
> http://opentox.ntua.gr:8080/model doesn't return anything and just
> hangs indefinitely
>  (therefore I've disabled all models-related probes)


Yes, I just noticed that and I fixed it. I had some problems with maven
(!) that's why I was late... Everything looks great now! 
I tried the following shell script:

for ((  i = 0 ;  i <= 1000;  i++  )); 
do 
curl -H Accept:text/uri-list opentox.ntua.gr:8080/model > /dev/null; 
done

According to http://opentox.ntua.gr:8080/monitoring (Java Melody) the
mean time was 2ms with max=3ms. There was a bug in my code before but
now I fixed it. 

I solved my problems with Hibernate... I'm using plain JDBC with C3P0
and I can say I'm much more satisfied. I created a ToxOtis module for
that (ToxOtis-db).

> 
> 2) https://opentox.ntua.gr/, where your documentation used to be
> located is not responding either


I'll put it back soon.

> 
> 3) http://opentox.ntua.gr/ returns "Under construction"


I just set up this machine from the beginning (new OS etc) so some
things are missing for the moment.

> 
> I presume you're in the process of fixing up things, so nothing
> serious to worry about -- just take care to fix those as well and let
> me know if you want me to re-enable some of the probes we were running
> in the past or define new ones.
> 


In general things are stable now but we might have some minor issues
that will be easy to solve.

Best Regards,
Pantelis


> Kind regards,
> Vedrin
> 
> On 11 April 2011 18:26, chung <chvng at mail.ntua.gr> wrote:
> > Dear All,
> >    I just deployed the new version of Jaqpot3 at
> > http://opentox.ntua.gr:8080 (source code at
> > https://github.com/alphaville/jaqpot3 ). Certain things need to be
> > optimized (JVM options, MySQL server, etc). On /monitoring you can find
> > a monitoring facility powered by JavaMelody while on /dbstats an XML is
> > retrurned with statistics about the database. I will soon circulate some
> > instructions and cURL commands we have used for testing. Please send me
> > if you notice any inconsistencies.
> >
> > Best Regards
> > Pantelis
> >
> >
> > On Mon, 2011-04-11 at 15:57 +0300, chung wrote:
> >
> >> Dear all,
> >>     Soon our services will be up and running so I'd like to share with
> >> you some extensions as well as some ideas.
> >>
> >> 1. Rescue Service
> >>     When one applies a DELETE on a resource (such as a model, a task or
> >> a bibtex resource) it is not really deleted from the database but it's
> >> deactivated. The deleted resource will return a status code 404 (not
> >> found) accompanied by an Error Report (in RDF). The deactivated
> >> resources however are still on the server and will remain there for one
> >> month (we have a lot of disk space, so we think we can cope with it...).
> >> Now, if the user wants to recover a resource that was deleter by mistake
> >> he can apply a get on /rescue?id={resource-id} or /rescue?uri={uri of
> >> previously deleted resource}. I was thinking that this can be a
> >> interface with access restricted to system admins only so it remains
> >> easy for the end-user to send an email to us and we can recover the
> >> deleted resource unless one month has passed and it has been deleted
> >> automatically. This can of remain out of specification.
> >>
> >> 2. BibTeX service
> >>     The BibTeX service the runs under jaqpot is tested however it will
> >> remain inactive or even useless if we don't find a way to associate
> >> BibTeX entries with other resources. I was thinking of a REST API that
> >> would look like the following...
> >>
> >> resource  /bibtex/{id}
> >> method   POST
> >> POSTed Parameters
> >>   1. resource_uri  [ The uri of the resource we want to associate with
> >> the bibtex entry. ]
> >> Header Parameters
> >>   1. subjectid [The authentication token. Specified by the underlying
> >> policy]
> >>
> >> This way we establish 1-to-many relationships between bibtex entries and
> >> other resources. Each BibTeX entry will provide a list of the resources
> >> that cite it. Inversely every algorithm and every model will potentially
> >> point to bibtex entry. Algorithms for example will carry a pointer to a
> >> bibliographic reference which the user will be able to download in
> >> various supported formats (such as the standard JSON-based BibTeX
> >> format). From the ontological point of view we need to introduce a new
> >> property, let's say ot:bibtex with domain ot:OpenToxResource and range
> >> knouf:Entry.
> >>
> >>
> >> 3. Fast RBF Neural Networks
> >>     An initial implementation of a high-performance RBF-NN training
> >> algorithm will be available. It has been tested on a variety of
> >> datasets.
> >>
> >> 4. Consensus Modeling
> >>
> >>     We currently work on the design of a simple consensus modeling
> >> algorithm. The algorithm accepts as input a series of model URIs and one
> >> of DoA models of the same length (For example, the user has to provide 2
> >> predictive models and 2 corresponding DoA "models" that were trained
> >> using the same dataset. The consensus model that is trained outputs the
> >> average of the predictions that are obtained by the sub-models that
> >> include the submitted instances in their DoA. A cURL request is expected
> >> to look like that:
> >>
> >>
> >> curl -X POST
> >> -d model_uri[]={model1}    -d model_uri[]={model2}
> >> -d doa[]={doa1 for model1} -d doa[]={doa2 for model2}
> >> host:port/algorithm/consensus
> >> -H subjectid:{token}
> >>
> >> As soon as the services are up again we'll ask from Vedrin to start
> >> smokeping tests and we expect better performance and stability.
> >>
> >> Best Regards,
> >> Pantelis
> >> _______________________________________________
> >> Development mailing list
> >> Development at opentox.org
> >> http://www.opentox.org/mailman/listinfo/development
> >>
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>