[Nicolas Noullet]

Hello,

Which version (number) have you installed ?

Is it icescrum.jar, icescrum.war in a custom Tomcat installation or iceScrum Server?

How did you have setup the access from outside?

[Nicolas Noullet]

Nous avons unifié les version d’iceScrum et il n’y a plus qu’un téléchargement. Si vous entrez une license, c’est iceScrum Pro, si vous n’entrez pas de license alors vous aurez les fonctionnalités Community comme avant.

Le problème persiste ? J’avais commis une faute de frappe dans mon précédent message, je voulais écrire :
Avez-vous essayé de redémarrer iceScrum Server ?

Est-ce que les logs contiennent des erreurs ? (icescrum.log, catalina.out, cf. la documentation https://www.icescrum.com/documentation/using-icescrum-server/#troubleshooting)

[Nicolas Noullet]

Bonjour Julien,

Avez-vous essayé de démarrer iceScrum Server ?

Est-ce une nouvelle installation ou un problème sur une ancienne installation ? Dans le cas d’une nouvelle installation je vous recommanderais plutôt d’utiliser icescrum.jar.

[Nicolas Noullet]

Hello Caroline,

First, the story copy issue is a bug of iceScrum R6#14.3, thanks for the report. We will probably release a fix version soon. I think that it has nothing to do with CPU usage.

If the CPU usage comes from a bug in the environment (the OS, Java or Tomcat itself) then there is not much we can do to help. Otherwise, if it comes from iceScrum then I can think of two possible causes:

• Spawning of threads which are never killed an consume CPU (e.g. unsuccessful connections to the DB that won’t close). However, the graphs you have uploaded on imgur (this is the first time I use imgur for actual work, thanks for that!) indicate a brutal rising while continuous thread spawning would be more linear.
• Heavy garbage collection, which happens when the JVM heap memory reaches the maximum defined by the -Xmx option. The JVM tries to free memory to avoid reaching the limit by removing dead objects but if there is a memory leak or if the Xmx is too low then it is doomed to fail with a « java.lang.OutOfMemoryError » error. This would typically cause a brutal rising of the CPU usage as the memory reaches its limit.

In order to be sure of the cause, can you please provide more information:
– JVM options (including Xmx and MaxPermSize): usually defined in CATALINA_OPTS
– Tomcat configuration file: server.xml
– Log files: icescrum.log and catalina.out
– Java version
– Tomcat version

You can write at support at kagilum dot com.

[Nicolas Noullet]

Gaël,

Glad to know that it works fine now. The user deletion has probably also deleted the default DB files that were preventing the setup to show up.

Anyway, we will investigate further to understand and fix the issue you came across.

Thanks for your enthusiastic feedback, have a nice day too 🙂

Nicolas

[Nicolas Noullet]

Hi Gaël,

There is probably a bug: the setup should be started again if the file creation fails. We will investigate.

The fact that the setup must be shown or not depends on the database. If your config has not been taken into account then I guess that the default database is used, which is written in prodDba.* files. I recommend that you start by deleting them to ensure that the setup is shown again at next startup.

Then, the « localhost » warning indicates that your config.groovy file is not taken into account. If you want it to be used then I recommend that you move it to a .icescrum directory in the home directory of the user who starts icescrum. This is the default place where icescrum looks for it if you don’t provide the path explicitly.

If your config.groovy file is found then its values will be used by default in the setup. Otherwise, you will have to enter them again. If you come across another permission issue when saving it then you don’t have to restart Tomcat, just try fixing the permission an save again.

Nicolas

[Nicolas Noullet]

Hi,

To do so, you will have to change the database connection URL by updating / adding a specific setting in the config.groovy file: dataSource.url

Here is its default value:
dataSource.url = "jdbc:hsqldb:file:prodDba;shutdown=true"

Here prodDba is the name of the DB and the name of the files which will be created. You can update the path like so to create them in the user home:
dataSource.url = "jdbc:hsqldb:file:~/prodDba;shutdown=true"

You can choose whatever path you want, however, I can’t guarantee that such change will fix your issue.

[Nicolas Noullet]

Well, that’s unexpected… The error message clearly states that it is a permission issue:
java.sql.SQLException: File input/output error prodDba.properties java.io.FileNotFoundException: prodDba.properties.new (Permission denied)

Another approach to solving your problem would consist in defining the connection to another DBMS, e.g. MySQL, if available. This solution provides the benefit that it will ensure that you use a safe DBMS (the default one, HSQLDB, is not reliable and should not be used for production).

If you really want to stay with HSQLDB and if additional checks on permissions give no solution then I can provide a way to manually set where iceScrum will create the HSQLDB file.

[Nicolas Noullet]

Thanks for your answer, removing the tomcat-jdbc jar was the right thing to do.

This new error indicates that the default database files cannot be created because the user who starts Tomcat lacks write permissions in the directory where iceScrum attempts to create them.

These files are created by default in the startup path (the directory from where you start Tomcat). Can you try adding the appropriate permissions?

[Nicolas Noullet]

Hi,

As indicated in the documentation:
Tomcat 7 (7.0.23 or greater), recommended: you need to remove the tomcatDir/lib/tomcat-jdbc.jar library.

Did you remove the tomcat-jdbc jar?

[Nicolas Noullet]

C’est en effet seulement la présence du paramètre qui est vérifiée. Quand à son utilité, elle est principalement technique et n’ayant pas implémenté moi-même cette API je n’en connais pas les détails.

[Nicolas Noullet]

Comme indiqué dans la documentation, il faut ajouter le paramètre « withStories » à true (https://www.icescrum.com/documentation/finder-api/)

Voici un exemple de requête cURL fonctionnelle :
curl -u votreUsername:votrePassword -H "Accept: application/json" 'http://votreServer/ws/p/VOTREPROJET/finder?withStories=true&story.type=3'

[Nicolas Noullet]

Google Drive refuses to provide a preview of your log files (probably because of their extension) and, as a « reader », I don’t have the permission to download them so I cannot look at your logs.

[Nicolas Noullet]

For the record, this has been answered here:

https://github.com/icescrum/iceScrum/issues/27

[Nicolas Noullet]

Hi,

An additional parameter that was not mentioned in the documentation is required! The documentation has now been updated accordingly. This parameter is called « manageTags » and it indicates whether tags should be updated.

Here is an example payload:

{
    "manageTags": "true",
    "story": {
        "tags": ["bogus_tag1", "bogus_tag2", "bogus_tag3"]
    }
}

You can alternatively use the string / coma based syntax for (which should not contain whitespaces) but it is mainly there to work with XML. JSON arrays are supported so you can use them.

Here is an example of a working cURL command:
curl -u yourUser:yourPassword -X PUT -H "Content-Type: application/json" -d '{"manageTags": "true", "story": {"tags": ["foo","bar"]}}' http://yourServer/ws/p/YOURPROJ/story/152

[Auteur]

Messages