headers
Franz Philipp Moser | 4 May 02:30
Picon

Problem with repositories/appdir and User prototype

Hi list,

I expirienced the following problem:

i hab 3 repositories. if the User prototype is located not in the first 
repository I get, the _name entry in the type.properties of User is not 
interpreted.

I mapped _name = my_email but i allways got an sql error that the column 
my_user.name is non existend. After rearanging the repositories, so that 
the repository with the User prototype is the first (0) and defining the 
appdir before all repositories, everything went right.

Can somebody reproduce this within their applications?

cu Philipp
--

-- 
XML is the ASCII for the new millenium
(Cocoon Documentation)
Permalink | Reply | 1 comment |
headers
Hannes Wallnoefer | 5 May 12:24
Picon
Gravatar

Re: Problem with repositories/appdir and User prototype

Hi Philipp,

2006/5/4, Franz Philipp Moser <philipp.moser <at> chello.at>:
>
> i hab 3 repositories. if the User prototype is located not in the first
> repository I get, the _name entry in the type.properties of User is not
> interpreted.
>
> I mapped _name = my_email but i allways got an sql error that the column
> my_user.name is non existend. After rearanging the repositories, so that
> the repository with the User prototype is the first (0) and defining the
> appdir before all repositories, everything went right.

That repository order would have an effect on this would be very
strange. I do think the problem is somewhere else.

However (and maybe related), a mapping of _name does/should not result
in a my_user.name property. _name is only used internally to know
which db field contains the user name for the purpose of
session.login(String, String). (I personally prefer doing the
username/password check myself and then use session.login(HopObject),
btw.)

To have the name property, you should define it in type.properties
without the leading underscore.

Hope this helps,
hannes
Permalink | Reply | 0 comments |
headers
Hannes Wallnoefer | 5 May 13:14
Picon
Gravatar

Outage of grazia.helma.at, need for new hardware

Hi folks,

as most of you probably noticed there was an outage on the Helma web
site and mailing lists over the last two days. This was caused by yet
another disk failure. I now had 3 disk failures over the last year,
all on disks of the same model and make I bought with a thomas krenn
server in 2003. Thankfully, this was the last disk of this batch I had
in use :-)

The bad thing this time is that although all *data* were mirrored and
backed up, the server configuration files were not, so I had to
reconfigure the whole batch of apache, postfix, mailman, bind, which
took me one night and most of one day. Well, I learned a bit and even
had some fun.

The bigger lesson to learn, apart from using more brains when setting
and backing up a server, is that it might be time to get some new
hardware. coletta.helma.at is currently a Compaq Deskpro with a 730
Mhz Pentium 3 and 512 MB of RAM and two (new) 40 Gb disks. I would be
willing to shell out the 600 Euros for a new Server (e.g.:
http://configure2.euro.dell.com/dellstore/config.aspx?c=at&cs=atbsdt1&kc=305&l=de&oc=SC054301&s=bsd&sbc=pedge_430sc_ide&fb=1
), but I think it would be nice if other Helma using entities would
contribute a few hundred €. The server is almost exclusively used for
Helma web and mail hosting, plus my personal email and web site.

Any givers/takers?
hannes
Permalink | Reply | 0 comments |
headers
Philipp Nowotny | 9 May 10:21
Picon

helma cluster at db-node-level

Hi (hopefully correct) list!

 

We tried to build a helma cluster at the db-node-level as it is described in the helma-documentation. So far so good – the replication works fine but it seems that the load distribution doesn’t work. “It seems” means that we are not quite sure because there obviously happens something. For example if we remove the slave server we get an error caused by the mysql-connector and we also recognize that the load on the slave varies. But the system monitor on the slave server shows no cpu usage – which is quite confusing. We hoped to distribute the queries between these two servers and therefore we would expect that the cpu usage would vary – or at least do something. Did we overlook something? Is there something we forgot?

 

Perhaps this is also a stupid question, but should we try this one: http://c-jdbc.objectweb.org/

  

Thanks in advance,

phil 

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Permalink | Reply | 1 comment |
headers
Michael Platzer | 9 May 10:43
Picon

Re: helma cluster at db-node-level

hi philipp!
>
> We tried to build a helma cluster at the db-node-level as it is 
> described in the helma-documentation.
>
can you please provide a link to which part of the documentation you are 
referring to?
and please send your db.properties, as well as the version of your 
mysql-jdbc-driver.

greets,
  michi
Permalink | Reply | 0 comments |
headers
Philipp Nowotny | 9 May 10:56
Picon

Re: helma cluster at db-node-level

Hi!

Helma doc: http://adele.helma.org/download/helma/documentation/documentation.html#GuideClusteringHelma

db.properites:
odessa.url=jdbc:mysql://localhost:3306,<slaveIP>:3308/db_odessa
odessa.driver=com.mysql.jdbc.ReplicationDriver
odessa.user=<user>
odessa.password=<pw>
odessa.autoReconnect = true 
odessa.roundRobinLoadBalance = true

connector:
mysql-connector-java-3.1.12-bin.jar

thanks,
phi

-----Ursprüngliche Nachricht-----
Von: helma-user-bounces <at> helma.org [mailto:helma-user-bounces <at> helma.org] Im Auftrag von Michael Platzer
Gesendet: Dienstag, 09. Mai 2006 10:44
An: Helma User Mailing List
Betreff: Re: [Helma-user] helma cluster at db-node-level

hi philipp!
>
> We tried to build a helma cluster at the db-node-level as it is 
> described in the helma-documentation.
>
can you please provide a link to which part of the documentation you are 
referring to?
and please send your db.properties, as well as the version of your 
mysql-jdbc-driver.

greets,
  michi

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Permalink | Reply | 1 comment |
headers
Michael Platzer | 9 May 11:02
Picon

Re: helma cluster at db-node-level

if you want to distribute the read-requests also to the master, then you 
will have to specify that server twice. i.e.

odessa.url=jdbc:mysql://<masterIP>:3306,<masterIP>:3306,<slaveIP>:3308/db_odessa

also see here: 
http://dev.mysql.com/doc/refman/5.0/en/cj-replication-connection.html

greets,
  michi

Philipp Nowotny schrieb:
> Hi!
>
> Helma doc: http://adele.helma.org/download/helma/documentation/documentation.html#GuideClusteringHelma
>
> db.properites:
> odessa.url=jdbc:mysql://localhost:3306,<slaveIP>:3308/db_odessa
> odessa.driver=com.mysql.jdbc.ReplicationDriver
> odessa.user=<user>
> odessa.password=<pw>
> odessa.autoReconnect = true 
> odessa.roundRobinLoadBalance = true
>
> connector:
> mysql-connector-java-3.1.12-bin.jar
>
> thanks,
> phi
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: helma-user-bounces <at> helma.org [mailto:helma-user-bounces <at> helma.org] Im Auftrag von Michael Platzer
> Gesendet: Dienstag, 09. Mai 2006 10:44
> An: Helma User Mailing List
> Betreff: Re: [Helma-user] helma cluster at db-node-level
>
> hi philipp!
>   
>> We tried to build a helma cluster at the db-node-level as it is 
>> described in the helma-documentation.
>>
>>     
> can you please provide a link to which part of the documentation you are 
> referring to?
> and please send your db.properties, as well as the version of your 
> mysql-jdbc-driver.
>
> greets,
>   michi
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
>   

--

-- 

DI Michael Platzer
technical director
--------------------------------------
knallgrau new media solutions gmbh
pezzlgasse 7|1, A-1170 wien
phone: +43 - 1 - 522 76 37
fax: +43 - 1 - 522 76 38
http://www.knallgrau.at

weitere News im Knallgrau Weblog:
  http://www.knallgrau.at/company/weblog
Permalink | Reply | 0 comments |
headers
Juerg Lehni | 9 May 18:36
Gravatar

Mysql connection problems

I sporadically encounter a problem with websites that have not been  
visited for a certain time. The first hit on any of the pages then  
generates this exception:

Java.lang.RuntimeException: Error retrieving NodeIDs:  
com.mysql.jdbc.CommunicationsException: Communications link failure  
due to underlying exception: ** BEGIN NESTED EXCEPTION **  
java.io.EOFException STACKTRACE: java.io.EOFException at  
com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1905) at  
com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2351) at  
com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2862) at  
com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571) at  
com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666) at  
com.mysql.jdbc.Connection.execSQL(Connection.java:2988) at  
com.mysql.jdbc.Connection.execSQL(Connection.java:2917) at  
com.mysql.jdbc.Statement.executeQuery(Statement.java:824) at  
helma.objectmodel.db.NodeManager.getNodeIDs(NodeManager.java:925) at  
helma.objectmodel.db.WrappedNodeManager.getNodeIDs 
(WrappedNodeManager.java:129) at helma.objectmodel.db.Node.loadNodes 
(Node.java:1548) at helma.objectmodel.db.Node.getSubnode(Node.java: 
1140) at helma.scripting.rhino.HopObject.jsFunction_getById 
(HopObject.java:427) at inv1.invoke() at  
org.mozilla.javascript.MemberBox.invoke(MemberBox.java:164) at ...

My database setup is pretty basic:

scriptographer.url = jdbc:mysql://localhost/scriptographer
scriptographer.driver = org.gjt.mm.mysql.Driver
scriptographer.user = scriptographer
scriptographer.password = ******

I'm on Debian, using MySQL 4.1.11-Debian_4sarge2-log and mysql- 
connector-java-3.1.12-bin.jar

I read somewhere that passing autoReconnect=true in the jdbc url  
might help, but read somewhere else that this is to be avoided.

Any hints on what could be wrong with my setup, and what I could do  
about it?

Jürg
Permalink | Reply | 10 comments |
headers
Stefan Rinner | 9 May 18:47
Picon

Re: Mysql connection problems


On May 9, 2006, at 6:36 PM, Juerg Lehni wrote:

> I sporadically encounter a problem with websites that have not been
> visited for a certain time. The first hit on any of the pages then
> generates this exception:

...

> Any hints on what could be wrong with my setup, and what I could do
> about it?

you are not alone ;-)

similar stuff happens on some of my hardly visited sites - but up to  
now I thought it's because of my rather old MySQL-Server - are you  
using an uptodate version?

- stefan
Permalink | Reply | 8 comments |
headers
Franz Philipp Moser | 9 May 19:02
Picon

Re: Mysql connection problems

Hi list,

We had a similar problem.

helma is not able to find out if the connection in the connection pool 
is still valid (has a connection to the server).

we made a cron job that made a http request to the app, to some spezial 
url that just gets one object from an internal collection.

this solved our problems. In recent helma/mysql setups I did't 
recognized such problems.

maybe you should post your versions of helma, too.

cu Philipp

Juerg Lehni wrote:
> I sporadically encounter a problem with websites that have not been  
> visited for a certain time. The first hit on any of the pages then  
> generates this exception:
> 
> Java.lang.RuntimeException: Error retrieving NodeIDs:  
> com.mysql.jdbc.CommunicationsException: Communications link failure  
> due to underlying exception: ** BEGIN NESTED EXCEPTION **  
> java.io.EOFException STACKTRACE: java.io.EOFException at  
> com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1905) at  
> com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2351) at  
> com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2862) at  
> com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571) at  
> com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666) at  
> com.mysql.jdbc.Connection.execSQL(Connection.java:2988) at  
> com.mysql.jdbc.Connection.execSQL(Connection.java:2917) at  
> com.mysql.jdbc.Statement.executeQuery(Statement.java:824) at  
> helma.objectmodel.db.NodeManager.getNodeIDs(NodeManager.java:925) at  
> helma.objectmodel.db.WrappedNodeManager.getNodeIDs 
> (WrappedNodeManager.java:129) at helma.objectmodel.db.Node.loadNodes 
> (Node.java:1548) at helma.objectmodel.db.Node.getSubnode(Node.java: 
> 1140) at helma.scripting.rhino.HopObject.jsFunction_getById 
> (HopObject.java:427) at inv1.invoke() at  
> org.mozilla.javascript.MemberBox.invoke(MemberBox.java:164) at ...
> 
> My database setup is pretty basic:
> 
> scriptographer.url = jdbc:mysql://localhost/scriptographer
> scriptographer.driver = org.gjt.mm.mysql.Driver
> scriptographer.user = scriptographer
> scriptographer.password = ******
> 
> I'm on Debian, using MySQL 4.1.11-Debian_4sarge2-log and mysql- 
> connector-java-3.1.12-bin.jar
> 
> I read somewhere that passing autoReconnect=true in the jdbc url  
> might help, but read somewhere else that this is to be avoided.
> 
> Any hints on what could be wrong with my setup, and what I could do  
> about it?
> 
> Jürg
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
> 

--

-- 
XML is the ASCII for the new millenium
(Cocoon Documentation)
Permalink | Reply | 0 comments |

Gmane