Hi Martin and Alex,
For us here at the moment it seems that SQLite bugs
are not responsible for our problem. At least applying
all possible SQLite-related patches does not change anything.
But two very interesting points have been discovered.
1. Consider a file .../OpenXPKI/Server/Workflow/Persister/DBI.pm
(1) If I remove a line 159:
##! 128: 'params from context: ' . Dumper $params
Then all tests run ok with "DEBUG=1" (that is with debug level of
the OpenXPKI server equal to 128).
(2) If instead of this line 159 I add the line:
sleep 20;
Then tests hang exactly as before.
(3) If instead of this line 159 I add the line:
sleep 5;
Then tests (with "DEBUG=1") run ok as in point (1).
Please note that tests pass with LESS sleeping time and fail
with MORE sleeping time. Do you think that less time
could model faster termination of the Dumper operation called
from this line?
All this could explain why tests pass ok at your testing machine
because yours in somewhat faster than ours.
Could you please try to reproduce our problem on your host
placing "sleep 20" or better "sleep 60" to this place
instead of the line 159?
Looks like OpenXPKI's Persister module has problems
with handling of the time. We have just tried today's patch
of Jim Brandt for persister part of the Workflow module, and
this patch does not change anything related to our picture.
Nonetheless this patch looks very much like really related to
our problem, but we do not understand how use this knowledge
to fix the problem.
Your ideas are really needed here.
===============================================================
2. Another very interesting point. This is about output of
several tests.
For example consider a test t/25_crypto/11_use_ca.
In the output (file 1034_output) of your (Linux) testing host I can see
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
UNSUPPORTED_ALGORITHM; __COMMAND__ => create_key; __PARAM__ => TYPE
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ => 11024;
__COMMAND__ => create_key; __PARAM__ => PARAMETERS, KEY_LENGTH
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ => 11024;
__COMMAND__ => create_key; __PARAM__ => PARAMETERS, KEY_LENGTH
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_curve; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, CURVE_NAME
ok 8 - RSA key created
ok 9 - Unsupported algorithm caught
ok 10 - Catching wrong keylength
ok 11 - Catching unknown algorithm
ok 12 - Catching RSA wrong keylength
ok 13 - Catching RSA unknown encryption algorithm
ok 14 - Catching EC unknown encryption algorithm
ok 15 - Catching EC wrong curve name
But on our testing host (under FreeBSD) I see:
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
UNSUPPORTED_ALGORITHM; __COMMAND__ => create_key; __PARAM__ => TYPE
ok 9 - Unsupported algorithm caught
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ => 11024;
__COMMAND__ => create_key; __PARAM__ => PARAMETERS, KEY_LENGTH
ok 10 - Catching wrong keylength
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
ok 11 - Catching unknown algorithm
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ => 11024;
__COMMAND__ => create_key; __PARAM__ => PARAMETERS, KEY_LENGTH
ok 12 - Catching RSA wrong keylength
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
ok 13 - Catching RSA unknown encryption algorithm
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_alg; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, ENC_ALG
ok 14 - Catching EC unknown encryption algorithm
# OpenXPKI::Exception =>
I18N_OPENXPKI_CRYPTO_BACKEND_API_COMMAND_ILLEGAL_VALUE; __VALUE__ =>
unknown_curve; __COMMAND__ => create_key; __PARAM__ => PARAMETERS, CURVE_NAME
ok 15 - Catching EC wrong curve name
Please make notice how the ORDER of exception reports and of OK statements
are different between Linux and FreeBSD.
Looks like FreeBSD follows the sequence of the perl source,
while Linux violates this sequence, maybe because of some parallel
processing or so.
How have your achieved this?
Do you think that this parallelism could be responsible for time races
or such?
All the best, Sergei
====================================================================
Sergei Vyshenski wrote:
> Hi Martin,
>
> Thank you very much for your comments.
> Sorry for delayed answer: was traveling.
>
> Martin Bartosch wrote:
>> IMO having multiple database connections should be no problem for a
>> modern database system. When forking a process, the kernel will
>> normally apply a copy-on-write policy on the variable data. The
>> program code should not be physically duplicated by a fork, I'd
>> expect the kernel to share the code between forked instances. So even
>> if you see multiple processes eating up 100 MB each, I'd expect a
>> real physical memory usage of much less.
>
> Please correct me, but modern behavior which you describe here
> is called threading technology. DB should be compiled with threading
> support enabled to achieve this. Also perhaps we need threaded perl to
> match treading functionality from the DBI/DBD side? We should at
> least stress this in docs.
>
>> With the current architecture in OpenXPKI we are limited to the
>> schemes that Net::Server offers. The preforking personality might be
>> usable for us, but the server architecture would have to be modified
>> somewhat to allow multiple client connection in one server process.
>> The main reason is the global CTX object which holds many resources
>> necessary for the daemon to work properly, including database handles
>> etc.
>> This can currently not easily be shared between concurring client
>> sessions living in the same server process. The fork() call
>> effectively isolates concurrent server processes.
>> Addressing this issue will be a major effort which personally I'd
>> like to address after the first release version. I agree that we
>> should have a look at this and optimize the server process.
>
> We have many servers (most probably running on the same host):
>
> 1) Apache
> 2) OX
> 3) DB
> 4) LDAP for CRL
> 5) LDAP for Certs
> 6) LDAP for Auth
>
> Each could either fork or (alternatively) thread,
> for each new user/request.
> You say that OX is hard to promote for support of threading.
> But all the rest servers can be. (Even sqlite has optional threading
> support.) Today we can adopt threading policy for all servers
> (with exception of OX). BTW, Net::Server has announced that
> threaded-capable personality is expected in the next version.
>
>> Question: do you really face perfomance problems in your environment?
>> In our project we are deploying OpenXPKI in a large scale environment
>> but we don't expect high load on the server. The main reason is that
>> the typical user will only access the server process about once a
>> year to obtain a new certificate, which should scale nicely even with
>> thousands of users.
>
> Agreed. But for me it would be a novelty if OX project declares that
> only 2-3 simultaneous users are allowed.
>
> All these worries started with the "DEBUG=1" problem. And I suspect that this
> could be due to too loose treating of resources. Because hanging of the
> OX server during tests is a crying sign about something absolutely impossible
> which is present in the OX code philosophy.
>
> Another idea presently under investigation here is a buggy DBD-SQLite driver:
>
> http://rt.cpan.org/Public/Dist/Display.html?Name=DBD-SQLite
>
> What exact versions of SQLite and of DBD-SQLite do you use at the testing
> host?
>
> All the best, Sergei
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> OpenXPKI-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openxpki-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
