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

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)

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

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

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.

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
>