|
|||||||
Empfehlung leistungsstarkes DMS
| Antwort |
|
|
Themen-Optionen | Ansicht |
|
#1
|
|||
|
|||
|
Hallo,
wir sind auf der Suche nach einem leistungsfähigen DMS/CR welches Imstande ist, ca. 10 mio. Knoten problemlos zu verarbeiten (versionieren, suchen, bearbeiten, locking). Ich bin mir sicher, dass fast alle kommerziell verfügbaren Tools diesen Anforderungen gerecht werden, das Problem ist in unserem Fall jedoch, dass das DMS Teil einer zu entwickelnden Software werden soll und wir mittlerweile schon fast davon abgekommen sind, ein bestehendes DMS einzubinden und es stattdessen komplett selbst zu entwickeln. Von der Idee her gefällt uns JLibrary sehr gut (auch unsre App. baut auf Eclipse-RCP auf), der mitgelieferte Client packt jedoch das Importieren von ca. 1 mio. Dateien nicht, somit konnten wir die Performance von dem verwendeten Content Repository (Jackrabbit) nicht testen. Hat irgendjemand Erfahrungen mit DMS' die die genannten Ansprüche erfüllen und sich problemlos in andre Applikationen integrieren lassen bzw. kann uns dazu jemand ein Content Repository empfehlen wenn wir an der Neuentwicklung nicht vorbeikommen? Beste Grüße und vielen Dank im Voraus, Arnold |
|
#2
|
|||
|
|||
|
Hallo Arnold,
Hm, was genau bricht denn ab? Die jLibrary-Entwickler versuchen eigentlich im Fehlerfalle immer zu helfen und Fehler zu fixen. Persönlich habe ich festgestellt das es manchmal Wunder wirkt der Java VM via xargs mehr RAM zuzuweisen. Warum arbeitet Ihr nicht direkt gegen JackRabbit, das wäre ja auch das eigentliche CR? Gruß Uwe |
|
#3
|
|||
|
|||
|
Hallo Uwe, danke für deine Antwort!
JLibrary habe ich aus dem Grund ausprobiert, da die API schon relativ viel von dem zur Verfügung stellt was auch wir später brauchen, den Client jedoch eig. nur zum "Stresstest" des CRs einsetzen wollen. Beim Importieren der Daten scheinen die Entwickler jedoch ein Speicherloch zu generieren, umso mehr Daten importiert wurden, umso länger dauert der Vorgang und bricht dann nach einer gewissen Zeit ab. Mehr RAM verzögert hier nur die Dauer des Abbruchs Hast du bzw. jemand andres hier bereits Erfahrungen mit Jackrabbit, kann das CR diese Datenmengen problemlos verarbeiten? Viele Grüße, Arnold |
|
#4
|
|||
|
|||
|
Hallo Arnold,
direkt mit JackRabbit habe ich noch keine Erfahrungen gemacht. Ich nutze momentan jLibrary eher im kleinen Umfeld als Standalone-Lösung für div. Sachen. Gruß Uwe |
|
#5
|
||||
|
||||
|
Hallo,
es ist mit Sicherheit nicht einfacher, für solche Anforderungen eine Lösung zu finden. Was ich mir noch ganz gut vorstellen könnte, wäre die Nutzung des Alfresco Repositories (was ja auch JSR-170 compliant ist) zu nutzen. Dies hätte auch den Vorteil auf einen Softwarelieferanten inkl. SLAs etc. zugreifen zu können, was in Projekten solcher Größe nicht unsinnig scheint. Grüße! Jörg Dennis Krüger
__________________
I am a CM Pro! Are you? www.cmpros.org |
|
#6
|
|||
|
|||
|
Hallo,
danke für die Meinungen! Sind im Moment auch dabei das Alfresco-Repository zu evaluieren. Ist zurzeit die ansprechendste Lösung. Viele Grüße, Arnold |
|
#7
|
|||
|
|||
|
Zitat:
Gruß Uwe |
|
#8
|
|||
|
|||
|
Abschließend bleibt zu sagen, dass wir uns für das Alfresco-Repository entschieden haben (mit JackRabbit als Umstiegslösung).
Gründe dafür sind einerseits die vorhandenen Benchmarks, Alfresco ist also auf diese Datenmenge auch getestet, andrerseits der Support für die API/das Repository. Ein Ausfall würde schlicht und einfach zu teuer sein. Bei einer OS-Lösung ist dieses Risiko einfach nicht abschätzbar und eine Fehlerbehebung äußerst aufwendig, da man mehr oder weniger alleine dasteht. Beste Grüße und nochmals vielen Dank für die Hilfe, Arnold Strasser Geändert von astrasser (25.04.2008 um 09:01 Uhr). |
| Antwort |
| Themen-Optionen | |
| Ansicht | |
|
|
Powered by vBulletin® Version 3.6.4 (Deutsch)
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Cara Europe Limited
vRewrite 1.5 beta SEOed URLs completed by Tech Help Forum and Chalo Na.





Linear-Darstellung
