I'll admit I haven't done any testing on the activation front. I'm
presently finalizing my development on a single instance of magnolia
before moving to the author/public combination. But when I access the
magnolia author/dev instance there's only ever been a long delay as the
persistence manager re-establishes connections. I figured I'd cross
that bridge when I get to it and was also considering bringing my worker
persistence manager back to life for the performance benefits.
I'll post here with what happens in a large activation and stale
connections soon.
--David
Anthony Ogier wrote:
David,
Just a little question regarding MySQL integration in Magnolia. Do your
custom Magnolia built with jackrabbit 1.2.3 really handles the MySQL
connection problem well ? Because I tried with the last version (trunk
9154) which uses jackrabbit 1.3.0 (which uses the same
SimpleDbPersistenceManager code except for 1 useless line) and the
"retry logic" didn't properly worked for me when activating big website
tree.
That's the reason why my company decided to release a persistence
manager which uses the connection pool from Tomcat directly. Check all
the information here if you're interested :
http://www.magnolia.info/wiki/Wiki.jsp?page=SettingUpMySQLRepositoryWithMagnolia3.1
Cheers,
Anthony
David Smith a écrit :
Entire hour for 20-30 pages?!! There's something very wrong in your
system if that's the case. I can export 70-80 pages in just a few
seconds and the export has never failed to load. Just tested it
actually .... about 40 seconds total time from hitting the export
button to download completed.
Just for the record though, my environment:
Mandrake Linux 10 on a Dell Optiplex (just a couple of years old)
MySQL version 4
Magnolia 3.0.3-SNAPSHOT (4/6/2007) custom build to use jackrabbit
1.2.3 (only changed the dependencies in the pom.xml files)
Tomcat 5.5.23 / Sun JDK 1.5.0_06
I've checked the coding for the persistence manager in jackrabbit
1.2.3 and it's the same as in 1.0.1 (currently shipped with magnolia
3.0.2CE) except they added some retry logic for when the db connection
goes bad.
Can you provide more detail for your export? Are you checking the
"Keep versions" checkbox? That would make the export much bigger (and
take longer).
--David
Miranda Jones wrote:
I have never been able to get the export tool (from the Tools menu)
to export XML correctly even with the "Format XML" box left
unchecked. I just tried this again to reverify (which took an entire
hour for about 20-30 pages!) and there are still line breaks all
through the paragraph content (sometimes even in the middle of HTML
tags).
This is definitely extremely undesirable. Even if re-saving the
paragraphs again worked, that is not a very good solution for a site
import with scores of pages and hundreds of paragraphs! It doesn't
work though, as the line breaks are turned into <br/>.
We use MySQL to store content, so right now our backup method is to
just make sure the MySQL databases are kept backed up. It would be
nice, though, to have a working XML export, too.
-- Miranda
David Smith wrote:
I'm sure the answer was in this thread somewhere, but I'll ask
because it's easier ....
Just out of curiosity, how did you do the export?
I've seen the right-click export method create the "pretty"
formatted indented xml which does cause problems on import. Using
the magnolia export tool (Export from the Tools menu on the left in
AdminCentral) and then making sure the "Format XML" checkbox is
clear always works for me.
--David
Jean Pierre Malrieu wrote:
It's even worse than I thought then, if it affects every backup-
restore cycle.
I can tell that my paragraphs (pasted from word in fck) CANNOT be
"reconverted" by saving again the paragraph. I don't want to be
too critical, because magnolia CE is an open source tool, and a
very promising one, but a CMS that cannot be saved and restored,
and in the case of magnolia CE, that cannot be updated, is not
ready for production.
JPM
Le 26 avr. 07 à 19:32, Sebastian Frick a écrit :
I remember this issue has already been reported in JIRA. Usually
you can "re-convert" those richtext-fields by clicking the
responsible dialog and save the data again. I don't think this
behaviour isn't caused by a different tomcat-version.
Nevertheless this issue is a big blocker for me...
Sebastian
Maintaining a site with magnolia proves to be a real nightmare.
The bugs in 3.0.1 forced me to update to 3.0.2.
I also downgraded from Tomcat 5.5.17 to 5.0.28, because of some
issues with table paragraphs, and because 5.0.28 is the version
magnolia ships with.
I exported everything and imported it back.
Most of the pages have problems now: line breaks appearing
randomly, tables created with fck editor which confuse content
and html, and so on...
What a mess!
Am I the only one to experience this?
At least we should be warned that one should not export and
import to magnolia instances running on a different version of
tomcat...
What's the point with exporting to xml if everything gets scrumbled?
JPM
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
