Chris Betts
2013-07-08 13:58:57 UTC
Hi Dave,
JXplorer uses the fairly low performance java 'swing' library, which
can cause it to seriously grind when it goes over large data sets (what's
"large" depends pretty much on how much memory and CPU you feed it).
That said, I've used it on a 70,000 user / 140,000 entry data set
without too much trouble on a fairly standard spec MacBook pro ... it took
up to 30 seconds to browse big branches of that directory which was
painful, but it did work!
You can try feeding java more memory by changing the command line used
to start it; something like -Xms1024m -Xmx1024m should do the trick?
As to dual editing; if you have a large data set with slow performance
and two folks try to modify the same entry I can see you could easily get
problems; JX doesn't "check" the entry before submitting changes, so odd
things could happen if dual edits are going in out of synch. (This isn't
necessarily a JX problem by the way; LDAP isn't transactional so you could
get into strife any time two people are editing the same stuff). I'd need
to know a bit more about exactly what operations they were trying to do,
but in general dual editing an LDAP directory is best avoided unless the
operators are working on different parts of the tree. (There are tricks to
avoid problems when using automated systems; you can splice the equivalent
of a 'record lock' into a software system with a bit of a hack, but that's
not much use to human users generally).
Anyway, really sorry to hear you've been having problems, and let us
know how you go with expanding the memory available, and whether that helps!
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456
JXplorer uses the fairly low performance java 'swing' library, which
can cause it to seriously grind when it goes over large data sets (what's
"large" depends pretty much on how much memory and CPU you feed it).
That said, I've used it on a 70,000 user / 140,000 entry data set
without too much trouble on a fairly standard spec MacBook pro ... it took
up to 30 seconds to browse big branches of that directory which was
painful, but it did work!
You can try feeding java more memory by changing the command line used
to start it; something like -Xms1024m -Xmx1024m should do the trick?
As to dual editing; if you have a large data set with slow performance
and two folks try to modify the same entry I can see you could easily get
problems; JX doesn't "check" the entry before submitting changes, so odd
things could happen if dual edits are going in out of synch. (This isn't
necessarily a JX problem by the way; LDAP isn't transactional so you could
get into strife any time two people are editing the same stuff). I'd need
to know a bit more about exactly what operations they were trying to do,
but in general dual editing an LDAP directory is best avoided unless the
operators are working on different parts of the tree. (There are tricks to
avoid problems when using automated systems; you can splice the equivalent
of a 'record lock' into a software system with a bit of a hack, but that's
not much use to human users generally).
Anyway, really sorry to hear you've been having problems, and let us
know how you go with expanding the memory available, and whether that helps!
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456
Sorry to pester, but weâve had a system failure using JXPlorer, and
would like to discuss with anyone with a similar experience.
We have been using it for several years, but with a database of several
hundred users. Recently this has increased to approx. 15,000 users and we
have witnessed a serious fall-off in performance, aswell as the issue
mentioned above. We had 2 operators using JXPlorer (via the browser
console) at the same time, and found that two key tables âlostâ entries
(from the end). We have stopped using JXPlorer via this method and started
using it in batch mode ie using âLDAPModifyâ.
1. Is 15000 an unrealistic number of records ?
2. Is the batch method going to provide a more consistent result?
3. Would installing the latest version provide any improvements?
Currently using JXv3.2.
Weâre not seeking to blame anyone or gain compensation, just get advice.
*David Why *
*CA Support Engineer*
*0121 3350656*
*07733 312485*
would like to discuss with anyone with a similar experience.
We have been using it for several years, but with a database of several
hundred users. Recently this has increased to approx. 15,000 users and we
have witnessed a serious fall-off in performance, aswell as the issue
mentioned above. We had 2 operators using JXPlorer (via the browser
console) at the same time, and found that two key tables âlostâ entries
(from the end). We have stopped using JXPlorer via this method and started
using it in batch mode ie using âLDAPModifyâ.
1. Is 15000 an unrealistic number of records ?
2. Is the batch method going to provide a more consistent result?
3. Would installing the latest version provide any improvements?
Currently using JXv3.2.
Weâre not seeking to blame anyone or gain compensation, just get advice.
*David Why *
*CA Support Engineer*
*0121 3350656*
*07733 312485*