headers
Hannes Wallnoefer | 15 Apr 16:16
Picon
Gravatar

HelmaSwarm 0.9

Hi all,

I just uploaded HelmaSwarm 0.9, the first complete Helmaswarm release.
HelmaSwarm is a tool to build Helma clusters, a group of Helma
instances forming one virtual server.

Download:
http://adele.helma.org/download/helma/contrib/helmaswarm/
Browse CVS:
http://adele.helma.org/source/viewcvs.cgi/extensions/helmaswarm/?cvsroot=hop

HelmaSwarm uses asynchronous JGroups communication to
distribute/coordinate cache and session state. This release should
work with all Helma snapshots from CVS HEAD dated March 25 or later.
It will not work with Helma 1.4.3 or any other Helma 1.4 release or
snapshot.

A note to testers of previous versions of HelmaSwarm: The config file,
config file app property and jar file name changed today. Make sure to
update your properties and remove any old jar files from lib/ext.

If you try it out please let me know if and how well it works!

Hannes
Permalink | Reply | 0 comments |
headers
Hannes Wallnoefer | 15 Apr 16:53
Picon
Gravatar

Garbage Collection problems with Jpeg reading/writing

Hi lists,

The folks at orf.at recently updated one of their servers to a recent
Helma snapshot and ran into a problem with garbage collection problem
caused by imaging operations and most likely linked to Jpeg
decoding/encoding using the new javax.imageio.* package. The problem
seems to be that the Jpeg reader/writer classes allocate a lot of
system resources which are only freed in the finalize method, which is
only called at garbage collection time, which caused the garbage
collector to take very long to run, blocking the application for
several seconds. At least our own testing and several bugs in the Java
bug db point in that direction:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4827358
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4867874
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4868479

(Note that while all these bugs are marked as fixed with JDK 1.5, the
problems occurred with 1.5 as well as 1.4.2.)

In response to these problems, I switched Image decoding back to the
old java.awt.Toolkit.getDefaultToolkit().createImage() method on the
helma_1_4 branch. Temporarily, also CVS HEAD was back to the old way,
but as of today we're back to using ImageIO.read() again on HEAD.

As a second measure, I made sure graphics contexts are disposed within
the image object and improved the Image.dispose() function to better
clean up resources. I also added a reference page for Image.dispose()
<http://helma.org/stories/77631/>. This function should always be
called by applications on Image objects once they aren't needed any
(Continue reading)

Permalink | Reply | 0 comments |
headers
tobias.schaefer | 19 Apr 18:24
Picon
Favicon

repositories

hallo

zuerst wollte ich ja schon fast einen vermeintlichen bug melden, aber jetzt bin ich selber drauf gekommen,
wo mein irrtum herrührte.

daher möchte ich erstmal die neue repository-funktionalität überbordend lobhudeln: das ist fast
schon eine art erlösung, vom immerwährenden ein- und auspacken eines zip-files oder von verqueren
symlinks innerhalb einer applikation.

der entwicklung von modularen strukturen und der verbesserung der bisher vorhandenen libraries wird das
m.e. ungeheuren vorschub leisten können.

dafür ganz großen dank an alle, die an der repository-lösung beteiligt waren.

was ich anfangs noch falsch gemacht habe (stichwort vermeintlicher bug), möchte ich aber dennoch verraten:

anfangs dachte ich, die applikation selbst wird wie bisher definiert, evtl. eben mit dem appdir pfad in apps.properties.

*dem ist nicht so.*

eine helma app ist nun, wenn ich das richtig sehe, nur noch ein virtuelles konstrukt, dem beliebig viele
(gibt's ein maximum?) repositories zugeordnet werden.

an erster (bzw. nullter) stelle, steht dabei eben der basis-code für diese applikation.

im fall von antville, beispielsweise, schaut die neue "verdrahtung" in apps.properties dann so aus
(inkl. aller libraries, die natürlich dann auch entsprechend im app verzeichnis vorhanden sein müssen):

antville
antville.static = /apps/antville/static
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hannes Wallnoefer | 21 Apr 15:03
Picon
Gravatar

Re: repositories

Hi Tobi,

On 4/19/05, tobias.schaefer <at> orf.at <tobias.schaefer <at> orf.at> wrote:
> hallo
> 
> zuerst wollte ich ja schon fast einen vermeintlichen bug melden, aber jetzt bin ich selber drauf
gekommen, wo mein irrtum herrührte.
> 
> daher möchte ich erstmal die neue repository-funktionalität überbordend lobhudeln: das ist fast
schon eine art erlösung, vom immerwährenden ein- und auspacken eines zip-files oder von verqueren
symlinks innerhalb einer applikation.
> 
> der entwicklung von modularen strukturen und der verbesserung der bisher vorhandenen libraries wird
das m.e. ungeheuren vorschub leisten können.

Ja, stichwort helmaLib bundeln im naechsten Helma-release.

> 
> dafür ganz großen dank an alle, die an der repository-lösung beteiligt waren.
> 
> was ich anfangs noch falsch gemacht habe (stichwort vermeintlicher bug), möchte ich aber dennoch verraten:
> 
> anfangs dachte ich, die applikation selbst wird wie bisher definiert, evtl. eben mit dem appdir pfad in apps.properties.

Man kann appdir noch verwenden (backwards-komatibilitaet), aber dann
ignoriert Helma wahrscheinlich die repositories (so frei aus dem kopf
gesprochen).

> 
> *dem ist nicht so.*
(Continue reading)

Permalink | Reply | 2 comments |
headers
michael.platzer | 21 Apr 18:59
Picon

Re: repositories

Hi,

neben FileRepository und ZipRepository ist für unsere Zwecke vor allem ein
simples DirRepository notwendig, welche alle dort abgelegten Verzeichnisse
als Code-Repositories berücksichtigt.
Wir hätten nämlich (neben einem 'libraries'-Verzeichnis) gern ein
'modules'-Verzeichnis, in welches man einfach weitere Verzeichnisse
(=entpackte module) hineinlegen kann, und Helma berücksichtigt diese dann
sofort, ohne dass man an apps.properties schrauben muss. Ist das leicht
implementierbar? Falls ja, dann werden wir bald einen entsprechenden
Helma-Patch an die Liste hier schicken.

lg
  michi
Permalink | Reply | 1 comment |
headers
Hannes Wallnoefer | 22 Apr 18:00
Picon
Gravatar

Re: repositories

On 4/21/05, michael.platzer <at> knallgrau.at <michael.platzer <at> knallgrau.at> wrote:
> Hi,
> 
> neben FileRepository und ZipRepository ist für unsere Zwecke vor allem ein
> simples DirRepository notwendig, welche alle dort abgelegten Verzeichnisse
> als Code-Repositories berücksichtigt.
> Wir hätten nämlich (neben einem 'libraries'-Verzeichnis) gern ein
> 'modules'-Verzeichnis, in welches man einfach weitere Verzeichnisse
> (=entpackte module) hineinlegen kann, und Helma berücksichtigt diese dann
> sofort, ohne dass man an apps.properties schrauben muss. Ist das leicht
> implementierbar? Falls ja, dann werden wir bald einen entsprechenden
> Helma-Patch an die Liste hier schicken.

Ja, ziemlich leicht: der schluessel dazu ist, dass die enthaltenen
FileRepositories in der methode isScriptRoot() true zurueckliefern.
Das koennte man zum beispiel bewirken, indem man im root-repository in
der methodw update() die sub-repositories mit parent null anlegt.

hannes

> 
> lg
>   michi
> 
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Zumbrunn | 23 Apr 21:36
Gravatar

Re: How do I get href method to use proper accessname

In case someone else ever gets stuck in the same way I did...  Here's 
the very anecdotal resolution of this rather ancient call for help :-)

Ever since I had this problem, I used a patched/hacked version of the 
helma.jar as a workaround. In order to be able to get rid of this 
stupid diff and get back on track, using an unmodified helma version, I 
finally looked into this again. So, it turns out I just needed to add 
'name' to my type.properties file. That's it. That's all it was.

Instead of this...

Page/type.properties:
     _children = collection(Page)
     _children.accessname = name
     _name = name

...I just needed this...

Page/type.properties:
     _children = collection(Page)
     _children.accessname = name
     _name = name
     name

Problem solved. Finally!

:-)

/czv
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hannes Wallnoefer | 25 Apr 13:55
Picon
Gravatar

Re: How do I get href method to use proper accessname

On 4/23/05, Chris Zumbrunn <chris <at> zumbrunn.com> wrote:
> In case someone else ever gets stuck in the same way I did...  Here's
> the very anecdotal resolution of this rather ancient call for help :-)
> 
> Ever since I had this problem, I used a patched/hacked version of the
> helma.jar as a workaround. In order to be able to get rid of this
> stupid diff and get back on track, using an unmodified helma version, I
> finally looked into this again. So, it turns out I just needed to add
> 'name' to my type.properties file. That's it. That's all it was.

Oops, I'm sorry I didn't see this at the time or your first posting.
In fact, the property used for a collection's accessname must be
mapped as an ordinary property of the child object. I reckon it's a
bug that you don't get some error message logged if you don't.

As far as _name is concerned, I don't think it is used anywhere
besides providing session.login(name, pw)/app.registerUser(name, pw)
functionality.

Hannes

> 
> Instead of this...
> 
> Page/type.properties:
>      _children = collection(Page)
>      _children.accessname = name
>      _name = name
> 
> ...I just needed this...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane