Messages

We also experienced a PermGen memory error under Glassfish (which I'm led to believe is partially based on Tomcat).  The error seemed to be exacerbated by frequent autodeploys.  We tried bumping up our maxPermSize as well, but that only delayed the problem.  In the end we appear to have solved this by upgrading to Glassfish (v2.1), but in the case of Tomcat, you could try the AntiJarLocking settings.

Interesting, thanks for the explanation.  Since we can't guarantee that users will hit the 'logout' button, this potentially affects every konakart installation. Over time, the SESSIONS table will grow with expired sessions, which will start to impact performance at a certain point. And storage.

I can't see a valid reason to keep expired sessions; the table contains a key, expiry date, value (customer id?) and store_id.  It's an unreliable indicator of customer activity, as the record is normally deleted if the customer officially logs out. It's only when a logout is not done that the record persists.

So as far as I can tell, expired sessions are useless and problematic and should be deleted?

Apart from running a batch script to delete them, some other ideas for automatic deletion are:

• Would konakart consider adding a session cleanup option as part of their housekeeping threads, like the cache thread?


• How about using an HttpSessionListener to invoke a konakart session cleanup thread when an HttpSession expires? Just using the HttpSession expiry as a convenient event trigger for invoking a cleanup thread, even though the HttpSession is different to a konakart session.

Anyway, the moral of the story seems to be: keep the SESSIONS table lean for optimal performance.

-- Clinton

Hi;
  we are getting several "Duplication sessionId created" warnings, generated from SecurityMgr.java:login:148, using konakart v3.2.0.0.

The full warning text is: " Duplicate sessionId created. We advise to clear out old sessions using the admin app since thi will affect performance."

Is the affect on performance the extra time required to recalculate and persist a sessionId, in the event of a duplicate? Or something more sinister?

I've checked our session table and we have 45,000 (!!!) sessions. What causes these sessions to accumulate and what can we do to reduce this build-up from occurring?  I know there's an admin function to remove old sessions, but I'm trying to understand the root cause, eg: is this a side effect of a Denial of Service attack?

-- Clinton

Hi,
  just wondering if there are plans to put some Manifest.mf version information in eg: konakart.jar?

Apologies if it's there already, we are using an older version - hard to tell exactly which version, since it's not in the manifest ;-)

This would make it easy for users to identify which version of the engine they are using, for customised installations.  Or is there an easier way?

-- Clinton

2 years later...I also encountered this same problem.  I did indeed try to deploy a second konakart instance, using shared konakart.properties torque settings.

Code Select Expand

torque.applicationRoot = .
torque.database.default = store1
torque.database.store1.adapter=oracle
torque.dsfactory.store1.factory=org.apache.torque.dsfactory.JndiDataSourceFactory
torque.dsfactory.store1.jndi.path=jdbc/kkbase

When I ensured I had unique settings on each konakart instance for the above, the problem went away... hope this helps, because I couldn't find an explicit reference to the exact cause in the previous comments.

Hi there,
  konakart is distributed under the terms of the Lesser GPL, which enables other companies to customise konakart and on-sell it (thankyou).

What's confusing me is the code under the konakart/custom/ directory, which contains a copyright notice:

Code Select Expand


// (c) 2006 DS Data Systems UK Ltd, All rights reserved.
//
// DS Data Systems and KonaKart and their respective logos, are
// trademarks of DS Data Systems UK Ltd. All rights reserved.
//
// The information in this document is free software; you can redistribute
// it and/or modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
//
// This software is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
// Lesser General Public License for more details.


Can I have some guidance on how developers are meant to deal with this copyright notice, given we are potentially modifying these source files to suit our own purposes?  Eg: the copyright claims "no warranty" but a commerical offering would have a warranty...

I'm a developer not a lawyer. One possible solution would be to remove the above copyright from the custom source code, on the understanding the code is there to be modified...

-- Clinton

Hello, do the good folk at konakart consider the duplicate jars inside the zip distribution to be a problem?

Removing these duplicates will eliminate a potential source of error as well as shave dozens of Megabytes off the overall file size.

I understand this is probably done for convenience and because "disk space is cheap" but given the distribution file size has now exceeded 100Mb you might want to consider a mitigation strategy for the future.

Eg: com.ibm.icu_3.8.1.v20080530.jar exists under konakart/webapps/birtviewer/WEB-INF twice... 4.1Mb
4 instances of axis.jar
3 instances of db2jcc.jar
3 instances of ojdbc14.jar
All of the above are over 1Mb each. So if you were to reduce all the duplicates above that's an immediate saving of approx 14Mb.

One possible way to manage this would be to define some sort of common directory and let the install procedures make copies of the files.  And/or use ant to manage the dependencies. 

Just a suggestion.

Thanks Brian, this will be useful for people behind a firewall (assuming port 80 isn't blocked) who wish to browse the features of konakart prior to installation, or for developers who want to compare behaviour against the base release.

- Clinton

We believe there is an error with the Oracle update script: konakart/databases/Oracle/upgrade_2.2.0.6_to_2.2.0.7.sql

The error prevents anyone from logging in to the admin app.  A sample of the error is:

  INSERT INTO kk_role_to_panel (role_id, panel_id, can_edit, can_insert, can_delete, date_added) VALUES (kk_role_seq.nextval,  1, 1,1,1,sysdate);

Since kk_role_seq.nextval is used, this results in an ascending no. of role_id's, whereas there are only 4 roles defined. The MySQL update script shows the real intent:

  INSERT INTO kk_role_to_panel (role_id, panel_id, can_edit, can_insert, can_delete, date_added) VALUES (1, 1, 1,1,1,now());

Many thanks to my colleague Tim for helping fix this problem and for creating the attached ammended upgrade script, which allowed us to login using the admin@konakart.com user.

Some extra doco on this subject would have been helpful, unless I missed it?

- Clinton

Hello Brian,
  I've checked the database configuration table and our ONE_PAGE_CHECKOUT is true.
I can drive the app through to the "Payment" screen, and even place a successfull order using cash-on-delivery.

Look forward to the rpc file in the next release.

- Clinton

Thanks Brian,
  the only *.rpc file I can see in the entire konakart 2.2.0.7 distribtution, is under konakartadmin. Should there be an equivalent for the konakart app ?

I've only briefly looked at the admin app to date. I don't think we are using single page checkout, I'll have to get back to you on that next week.

- Clinton.

Hello, I've noticed the following error in our server log, but I can't find any *.rpc files in the distribution:

[#|2007-10-26T11:00:11.767+1000|INFO|sun-appserver-pe9.0|javax.enterprise.system
.container.web|_ThreadID=14;_ThreadName=httpWorkerThread-8080-0;|WebModule[/kona
kart] ServletContext.log():ERROR: The serialization policy file '/D2828CFD7DB67C
D8792DB76C642A3F08.gwt.rpc' was not found; did you forget to include it in this
deployment?|#]

[#|2007-10-26T11:00:11.783+1000|INFO|sun-appserver-pe9.0|javax.enterprise.system
.container.web|_ThreadID=14;_ThreadName=httpWorkerThread-8080-0;|WebModule[/kona
kart] ServletContext.log():WARNING: Failed to get the SerializationPolicy 'D2828
CFD7DB67CD8792DB76C642A3F08' for module 'http://localhost:8080/konakart/'; a leg
acy, 1.3.3 compatible, serialization policy will be used.  You may experience SerializationExceptions as a result.|#]

How can I eliminate this error?

- Clinton

Are the duplicate images in konakart really necessary?
I'm a bit confused as to why they exist.

Eg: in konakart/de_DE/buttons/

button_back.gif
button_confirm_order.gif
button_continue.gif
button_login.gif
button_update.gif

Which also appear in konakart\webapps\konakart\images\de_DE\buttons. The same exists for en_GB and es_ES.

Would it be simpler and tidier to remove such duplicates?

- Clinton

Yes my workplace does have port 8090 blocked. Can access this URL from home instead.
Thanks,
  Clinton.

Hello Brian, is the above link still working?  I tried to access it on (AEST) 25 Oct 07 at 1700 (which I think equates to 25Oct07 0700 GMT) and got a timeout error. 

I was hoping to compare functionality between your deployed version and mine.

Thanks,
  Clinton