You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(22) |
Jun
(10) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
|
Mar
(8) |
Apr
(11) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(12) |
Nov
|
Dec
|
2005 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(20) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(25) |
Sep
(6) |
Oct
(1) |
Nov
(3) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(1) |
Nov
(3) |
Dec
|
From: Chema C. C. <jmc...@ig...> - 2007-11-23 00:03:13
|
El jue, 22-11-2007 a las 18:03 +0100, Javier Fernandez escribi=C3=B3: > On Thu, Nov 22, 2007 at 04:09:29PM +0100, Antia Puentes Felpeto wrote: > > Hi! > >=20 > > When I execute a script that does inserts and updates in a database a > > lot of problems of memory are appeared. I attach the code of the script > > and the logs of valgrind for the functions "create_accounts" and > > "update_accounting_with_invoice_data", being run for a small set of > > documents. > >=20 > > Maybe the problem is the way fisterra-base manages the pool of > > connections.=20 > Memory leaks related to f_parameter_manager are due to parameters=20 > hash_map, allocated during f_parameter_manager_init method. This memory=20 > should be freed using f_parameter_manager_shutdown at end of program.=20 >=20 > However, these memory leaks are not important for this script, because=20 > when scrit ends its operations all memmory will be released. As far as i could see at the valgrind logs there are not important leaks=20 that could lead to a real problem, only one related to the retrieval of=20 persons, but as you could see at the end of the report the amount that=20 is not disposed at the end of the execution is only 200kb. So leaks are not the problem, you could check during the execution of the program the=20 There is a problem with the attached C source file, because it is a tar file with the valgrind logs, it is not the update_accounting.c file :( Best Regards, --=20 Chema Casanova http://blogs.igalia.com/chema/ +34 654 212 875 |
From: Javier F. <jfe...@ig...> - 2007-11-22 17:03:40
|
On Thu, Nov 22, 2007 at 04:09:29PM +0100, Antia Puentes Felpeto wrote: > Hi! > > When I execute a script that does inserts and updates in a database a > lot of problems of memory are appeared. I attach the code of the script > and the logs of valgrind for the functions "create_accounts" and > "update_accounting_with_invoice_data", being run for a small set of > documents. > > Maybe the problem is the way fisterra-base manages the pool of > connections. Memory leaks related to f_parameter_manager are due to parameters hash_map, allocated during f_parameter_manager_init method. This memory should be freed using f_parameter_manager_shutdown at end of program. However, these memory leaks are not important for this script, because when scrit ends its operations all memmory will be released. -- Javier Fernández García-Boente Ingeniero en Informática mailto:jfe...@ig... Igalia http://www.igalia.com Telf. +34 981 91 39 91 Fax. +34 981 91 39 49 |
From: Antia P. F. <apu...@ig...> - 2007-11-22 15:09:56
|
Hi! When I execute a script that does inserts and updates in a database a lot of problems of memory are appeared. I attach the code of the script and the logs of valgrind for the functions "create_accounts" and "update_accounting_with_invoice_data", being run for a small set of documents. Maybe the problem is the way fisterra-base manages the pool of connections.=20 Regards, Ant=EDa. |
From: Bruno T. <bru...@po...> - 2007-10-06 18:13:49
|
Hi API, I guess it is. UDDI is basicaly a name server for fisterra soap applications, but it is still to be really tested. Take care. > And about how split this ... well I think that only work with fisterra > could show us the perfect groups of packages, but, uddi is a "optional" > package? > > > === > API (api...@ig...) > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Fisterra-devel mailing list > Fis...@li... > https://lists.sourceforge.net/lists/listinfo/fisterra-devel > -- Bruno Teixeira |
From: API <api...@ig...> - 2007-09-28 06:13:14
|
> > Finally I followed an intermediate solution: instead of put each module in its > package, I splitted the modules in two categories: basic and extra. > > The basic modules are those that will be in every fisterra application for > sure (auth, calendar, document, payment and tax) and extra are the "optional" > packages (replication, uddi and migration). Each group has its > lib, -dbg, -doc and -dev package. > I think this is a good solution, because the modules in the basic group depend > on each other and they are used almost always together, and at the same time > we give more install options than all or nothing. > Anyway, if a particular module grows and it would be better in its own > package, it's better to split that package when that happens and not now. I think that this is a good idea. There are other projects that use this approach. For example, gstreamer, that have some packages that englobes several plugins (instead of one package for each plugin): gst-plugins-base gst-plugins-good gst-plugins-ugly gst-plugins-bad (Although probably, the last two packages are experimental packages, to include unstable or bad coded plugins) And about how split this ... well I think that only work with fisterra could show us the perfect groups of packages, but, uddi is a "optional" package? === API (api...@ig...) |
From: Alberto G. <ag...@ig...> - 2007-09-27 20:19:07
|
O Xoves 27/09/2007 ás 21:06, Jorge Barreiro Gonzalez dicía... > I can't assume the user has the database and the name-server > properly configured when they decide to do "apt-get install > fisterra2-distribution-server". Possibly the user doesn't know he > needs it yet. In addition, you could change the configuration of > your nameserver or database after been working with it. Regarding the database: there's no way to make sure that a database server is working and ready for the package to use. A user should be able to use a remote database and that's a valid configuration but impossible to detect automatically, so you can only tell him that Fisterra needs a database server to work, and point him to the configuration program. Of course you could run that configuration from the post-installation script, but ask the user first! The problem with the name server is the same. -- Alberto García González http://people.igalia.com/berto/ |
From: Jorge B. G. <yor...@gm...> - 2007-09-27 19:04:39
|
Continuing with the packaging work, I'm looking at the current configuration scripts in the fisterra-distribution packages. The script is useful, but you can run it only when you install the package, and the fisterra applications are complex ones. I can't assume the user has the database and the name-server properly configured when they decide to do "apt-get install fisterra2-distribution-server". Possibly the user doesn't know he needs it yet. In addition, you could change the configuration of your nameserver or database after been working with it. So my proposal is to provide a configartion script independent from the debian package, so the user could run it when it's needed. In the package configuration script could be given the option to configure fisterra at that moment or, if the user doesn't have the database and nameserver ready, give an advise that he can (and should) run the configuration script later. I'm even thinking in just install a default configuration file with the package, and mention the configuration script in the README file. The debian policy recommends this, and I've seen several packages that does it. What do you think? does it seems a good idea? Any other ideas? |
From: Jorge B. G. <yor...@gm...> - 2007-09-27 18:45:11
|
O M=E9rcores 19 Setembro 2007 10:42, Alberto Garcia escribiu: > O M=E9rcores 19/09/2007 =E1s 10:38, Xabier Rodriguez Calvar dic=EDa... > > > > The problem comes with bmodules. There are 10 modules, most with > > > 3 versions (common, client and server), and adding the -dev, -doc > > > and -dbg packages, there will be near 100 packages. It can be > > > really hard to work with that amount of packages. Not only for > > > creating them, but for using them. > > Indeed. I wouldn't create 100 packages of modules. =46inally I followed an intermediate solution: instead of put each module i= n its=20 package, I splitted the modules in two categories: basic and extra. The basic modules are those that will be in every fisterra application for= =20 sure (auth, calendar, document, payment and tax) and extra are the "optiona= l"=20 packages (replication, uddi and migration). Each group has its=20 lib, -dbg, -doc and -dev package. I think this is a good solution, because the modules in the basic group dep= end=20 on each other and they are used almost always together, and at the same tim= e=20 we give more install options than all or nothing. Anyway, if a particular module grows and it would be better in its own=20 package, it's better to split that package when that happens and not now. |
From: Maria I. F. T. <mif...@ig...> - 2007-09-25 09:14:07
|
Finally, in the first problem, I tried to add DISTDIR option to 'make' and now build process is completed successfully. I know that, with this change, the application won't work, but for the time being none unit test is made for this module (fisterra-repair) and after building none step more is executed, but in the future this should be changed (it would be only delete the line with module_makeargs in .jhbuildrc file in the slave). Nevertheless I'm going to have a look at fisterra-bmodule-auth. The second one I have found was solved erasing libgda of moduleset, because files for SQLite provider wasn't intalled (I had to delete the whole source code and installed files of the previous libgda build to allow that the application use correct gda files installed in the system). |
From: API <api...@ig...> - 2007-09-24 09:21:40
|
From: Xabier Rodriguez Calvar <xrc...@ig...> Subject: Re: [Fisterra-devel] problems with jhbuild-buildbot in fisterr= a Date: Mon, 24 Sep 2007 10:45:50 +0200 > O Xov, 20-09-2007 =E1s 04:10 +0200, Jorge Barreiro Gonzalez escribiu:= > > I also saw this, when I was testing fisterra-repair. That's because= = > > fisterra-repair always tries to install a file in /etc/pam.d, it do= esn't = > > matter what prefix or options you pass to the configure script. > > Look at this file: /src/server/etc/Makefile.am > > That directory is hard-coded in a line like: pamconfdir =3D /etc/pa= m.d > > There are two options, install this always as root, or to change th= at line. I = > > think that folder should depend on an option passed to the configur= e script. > = > I think if you are using the autotools you have the possibility of > specifying a directory which really installs everything under the pla= ce > you decide: > = > make install DESTDIR=3D/my/dir > = > Try this and if this doesn't work I can take a deeper look. > = You should read my answer to this problem, that I sent past Thursday (I= know that it is long), as make what you say is really easy, but it is not the rea= l problem = with this variable. =3D=3D=3D API (api...@ig...) |
From: Xabier R. C. <xrc...@ig...> - 2007-09-24 08:46:25
|
O Xov, 20-09-2007 =E1s 04:10 +0200, Jorge Barreiro Gonzalez escribiu: > I also saw this, when I was testing fisterra-repair. That's because=20 > fisterra-repair always tries to install a file in /etc/pam.d, it doesn't=20 > matter what prefix or options you pass to the configure script. > Look at this file: /src/server/etc/Makefile.am > That directory is hard-coded in a line like: pamconfdir =3D /etc/pam.d > There are two options, install this always as root, or to change that lin= e. I=20 > think that folder should depend on an option passed to the configure scri= pt. I think if you are using the autotools you have the possibility of specifying a directory which really installs everything under the place you decide: make install DESTDIR=3D/my/dir Try this and if this doesn't work I can take a deeper look. Greetings! --=20 Xabier Rodr=EDguez Calvar Enxe=F1eiro en Inform=E1tica Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: xrc...@ig... IGALIA http://www.igalia.com |
From: Javier F. <jfe...@ig...> - 2007-09-20 07:41:58
|
El mi=E9, 19-09-2007 a las 20:45 -0400, inf...@pi... escribi=F3: > Hi, > Has the channel change? I tried #fisterra > on irc.gimp.org and could not find anything. > Any help please. > Wayne >=20 The chanel has not change and is now active. Could you try again, please ? --=20 |
From: API <api...@ig...> - 2007-09-20 06:51:36
|
> I also saw this, when I was testing fisterra-repair. That's because > fisterra-repair always tries to install a file in /etc/pam.d, it doesn't > matter what prefix or options you pass to the configure script. > Look at this file: /src/server/etc/Makefile.am > That directory is hard-coded in a line like: pamconfdir = /etc/pam.d > There are two options, install this always as root, or to change that line. I > think that folder should depend on an option passed to the configure script. Well, you could made this to solve this concrete problem, but there are a problem You can configure other directories because is fisterra who use this, like the serverconfdir in the same Makefile.am. If we are compiling in a local directory, we can change the directory, and fisterra will find the file correctly. But this directory is hardcoded because who will use the file "fisterra" is the pam module, and to work properly, the file is needed to be on this directory. If we configure this directory to a local one, we can solve the problem making a `make install`, but the authentication will fail if we try to execute this. Currently, the auth module (on fisterra-bmodules-auth) uses pam to make the authentication, and uses the "hard-coded" file called "fisterra". In this way we can configure the authentication very easy, as there are several pam modules: using a file, using a ldap, etc. In this case, it is configured to use a pwd file. In theory, thinking in the project as an open project, it is simply an configuration example, there are any point on documentation that says that?, that explain how configure and how works the authentication, and that this is only a example? Another point: there are a problem with this implementation. As I say, the fisterra-bmodule-auth module uses the `fisterra` file to authenticate. This has a problem: what happens if you have several applications based on fisterra? (ie: fisterra-repair and fisterra-distribution). The problem is that to authenticate you'll be sharing the same authentication file. Well, when you start to work, you can have different acls, as this in on database, but at first, to authenticate, you share the pam.d fisterra, as it is used on fisterra-bmodules. Looking a cvs log at Makefile.am, you can see that at begining this authentication file was on fisterra-bmodules. This was because is shared, but was moved because in theory you use a concrete file for each application. But as I say, it is shared. If we make each concrete app to install his fisterra file, each one will be replacing the fisterra file of the others. This "shared approach" has sense if all the fisterra applications on a machine share his users, but Im not sure if we can suppose this at this moment. Other problem with this approach is that it is difficult to add new users, although with the acls, it is difficult to add users (in fact, this is more a "role" approach). Should be reviewed the fisterra-bmodule-auth? For example: in others applications based on fisterra, we don't use fisterra-bmodules-auth to authenticate, the app implements the authentication himself, and uses the database to manage the users that can authenticate, and to add users. === API (api...@ig...) |
From: Jorge B. G. <yor...@gm...> - 2007-09-20 02:09:09
|
O M=E9rcores 19 Setembro 2007 19:49, Maria Isabel Franco Trillo escribiu: > Hello > > I have installed jhbuild-buildbot for fisterra in my machine and I found > some problems in the process of building. > > First: > In the step of build for fisterra-repair module it fails because tries > to write in a directory where it hasn't permissions (this is /etc/pam.d) > and for this reason the process isn't completed successfully. This fail > happens when command "make install" is executing. > I don't know if I can do something to solve this. I also saw this, when I was testing fisterra-repair. That's because=20 fisterra-repair always tries to install a file in /etc/pam.d, it doesn't=20 matter what prefix or options you pass to the configure script. Look at this file: /src/server/etc/Makefile.am That directory is hard-coded in a line like: pamconfdir =3D /etc/pam.d There are two options, install this always as root, or to change that line.= I=20 think that folder should depend on an option passed to the configure script. > Second: > The other modules are built successfully and I'm trying to execute unit > tests for fisterra-base module in the slave. > > First time the system executed the step make-check and in this step the > command "jhbuild --moduleset=3Dfisterra.modules pathrun fisterra-base > make-check.sh", one of the fails appeared was: > > ** (Libfisterra: GNOME business applications development > framework:7200): WARNING **: Error: libpq.so.2: cannot open shared > object file: No such file or directory > ** ERROR **: f_da_provider_init: GDA provider does not exist > aborting... > > I solve the first error adding to path the place where the library > libpq.so.2 is but now the output is: > > Error: Could not find provider SQLite in the current setup > [...] > check_fisterra-base.c:146:F:Core:check_fisterra_base_sqlite: > ****************************************************** > The sqlite gda provider is not (properly) installed > There are certain tests that rely on that provider; so, > those tests will fail without actually being executed > ****************************************************** When I found the error complaining about the SQLite provider not found, I=20 solved it installing the package gda2-sqlite. But if (as you say) it works= =20 when you try it manually in your directory , may be that's not the problem= =20 (or it could be that when it works you are trying in other machine, where=20 that package is already installed). Anyway, test that you have the needed gda2-* packages. Regards, Yortx. |
From: <inf...@pi...> - 2007-09-20 00:44:59
|
Hi, Has the channel change? I tried #fisterra on irc.gimp.org and could not find anything. Any help please. Wayne |
From: Maria I. F. T. <mif...@ig...> - 2007-09-19 17:49:42
|
Hello I have installed jhbuild-buildbot for fisterra in my machine and I found some problems in the process of building. First: In the step of build for fisterra-repair module it fails because tries to write in a directory where it hasn't permissions (this is /etc/pam.d) and for this reason the process isn't completed successfully. This fail happens when command "make install" is executing. I don't know if I can do something to solve this. Second: The other modules are built successfully and I'm trying to execute unit tests for fisterra-base module in the slave. First time the system executed the step make-check and in this step the command "jhbuild --moduleset=fisterra.modules pathrun fisterra-base make-check.sh", one of the fails appeared was: ** (Libfisterra: GNOME business applications development framework:7200): WARNING **: Error: libpq.so.2: cannot open shared object file: No such file or directory ** ERROR **: f_da_provider_init: GDA provider does not exist aborting... I solve the first error adding to path the place where the library libpq.so.2 is but now the output is: Error: Could not find provider SQLite in the current setup [...] check_fisterra-base.c:146:F:Core:check_fisterra_base_sqlite: ****************************************************** The sqlite gda provider is not (properly) installed There are certain tests that rely on that provider; so, those tests will fail without actually being executed ****************************************************** I don't write all the output because is too long. This behaviour is in the slave. Then I execute "make -k check" in my directory, (not in the slave) where I have downloaded and installed fisterra-base by manual process, and all tests passed successfully. I think that to solve this in the slave I have to change or add a environment variable but really I don't know. If someone has an idea, could you help me? Third: Executing this tests in the slave the result of one is segmentation fault but in my directory it passed successfully. This behaviour seems stranged and I think that it can be solved substituing this code (in fisterra-base/ut/common/check_util.c in the test check_util_name_month): gchar* months[] = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"}; int i; for (i=1;i<13;i++){ fail_unless(strcmp(u_get_name_of_month(i), months[i])); fail_unless(strcmp(u_month_number_to_month_string(i), months[i])); } for that one: int i; for (i=1;i<13;i++){ fail_unless(!strcmp(u_get_name_of_month(i), months[i-1])); fail_unless(!strcmp(u_month_number_to_month_string(i), months[i-1])); } Because strcmp returns 0 if the strings are equals and fail_unless(0) make the test fails. And I think that the counter of the array it was wrong. I don't know what I can do with this because the next time the jhbuild-buildbot execute the step of update the sources will be overwritten and the test will fail again. |
From: Alberto G. <ag...@ig...> - 2007-09-19 08:43:04
|
O Mércores 19/09/2007 ás 10:38, Xabier Rodriguez Calvar dicía... > > The problem comes with bmodules. There are 10 modules, most with > > 3 versions (common, client and server), and adding the -dev, -doc > > and -dbg packages, there will be near 100 packages. It can be > > really hard to work with that amount of packages. Not only for > > creating them, but for using them. Indeed. I wouldn't create 100 packages of modules. -- Alberto García González http://people.igalia.com/berto/ |
From: Xabier R. C. <xrc...@ig...> - 2007-09-19 08:38:46
|
O Mar, 18-09-2007 =E1s 19:58 +0200, Jorge Barreiro Gonzalez escribiu: > Another thing I'm doing is splitting the packages. I divided libfisterra = in=20 > libfisterra-common, libfisterra-client and libfisterra-server. In additio= n=20 > every lib* package has its lib*-dev, lib*-dbg and lib*-doc package. >=20 > That division has its advantages. One can install only what really needs = and=20 > nothing else,and a library can evolve independently of the others (the au= th=20 > module could be upgraded and become binary incompatible with its previous= =20 > version. If there's only one big package with all modules, every module = must=20 > be upgraded without real changes. ). >=20 > The problem comes with bmodules. There are 10 modules, most with 3 versio= ns=20 > (common, client and server), and adding the -dev, -doc and -dbg packages,= =20 > there will be near 100 packages. It can be really hard to work with that=20 > amount of packages. Not only for creating them, but for using them.=20 >=20 > There are scripts for creating them, and metapackages for using them but = they=20 > are still a lot of packages. What do you think? Would be useful to have a= ll=20 > that packages, or would be better to just have bmodules splitted in commo= n,=20 > client and server packages?=20 I thinks it's a nice work! Greetings. --=20 Xabier Rodr=EDguez Calvar Enxe=F1eiro en Inform=E1tica Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: xrc...@ig... IGALIA http://www.igalia.com |
From: Jorge B. G. <yor...@gm...> - 2007-09-18 17:57:18
|
Hello, I'm updating the debian packages for fisterra, and changing same things on them. For example, I changed the rules script to use the cdbs system. Another thing I'm doing is splitting the packages. I divided libfisterra in libfisterra-common, libfisterra-client and libfisterra-server. In addition every lib* package has its lib*-dev, lib*-dbg and lib*-doc package. That division has its advantages. One can install only what really needs and nothing else,and a library can evolve independently of the others (the auth module could be upgraded and become binary incompatible with its previous version. If there's only one big package with all modules, every module must be upgraded without real changes. ). The problem comes with bmodules. There are 10 modules, most with 3 versions (common, client and server), and adding the -dev, -doc and -dbg packages, there will be near 100 packages. It can be really hard to work with that amount of packages. Not only for creating them, but for using them. There are scripts for creating them, and metapackages for using them but they are still a lot of packages. What do you think? Would be useful to have all that packages, or would be better to just have bmodules splitted in common, client and server packages? |
From: Bruno T. <bru...@po...> - 2007-09-14 18:44:14
|
Hi Antia, the reason for the "strange" error message is because the "f_com_corba_model_delegate_test_session()" function is called before the server is contacted, and if this function returns TRUE there should be no reason for a CORBA error, but I guess you just found one! Maybe the error message from CORBA it self - "IDL:omg.org/CORBA/COMM_FAILURE:1.0" - should be more especific, but that is up to the people from CORBA. Take care. Antia Puentes Felpeto wrote: > Hi!, > > the problem is resolved by changing the value of the ORBIT parameter > "-ORBInitialMsgLimit" in the file: client/com/f_communication_layer.c > > This parameter has the next meaning: > > "ORBInitialMsgLimit=# Amount of data accepted on first method > invocation. Succeeding method invocations are not limited. This option > is used to prevent DOS attacks - ie. opening a connection to service, > sending huge amount of junk data." > > > Thanks Chema for the information :D > > > Regards. > > > > > > > El lun, 03-09-2007 a las 20:06 +0200, Antia Puentes Felpeto escribió: >> Hi! >> >> I have a problem with CORBA: >> >> "No se pudo contactar con el servidor Fisterra: Unexpected communication >> error, the server is up and running but there appears to have been an >> error. IDL:omg.org/CORBA/COMM_FAILURE:1.0" >> >> This error is produced when I try to send a list of 10.000 elements but >> it works well for a smaller list of 5.000 elements, in detail I use the >> next service for testing called: >> >> >> "boolean check_corba_error_retrieving_accounts( >> in unsigned long long enterprise_code, >> out f_data::BarnacleList account_list, >> in session::session_object session) raises >> (f_common::FisterraException)" >> >> that returns a list of accounts of size 10.000. >> >> The exception appears in the method asociated in the >> f_com_corba_model_delegate.c when you evaluate the condition: >> >> result = !f_com_corba_handle_corba_exception_with_message("Unexpected >> communication error, the server is up and running but there appears to >> have been an error. ",&ev, error) && result; >> >> >> Tell me if you have any idea of the cause of the problem. >> >> Thanks! >> >> > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Fisterra-devel mailing list > Fis...@li... > https://lists.sourceforge.net/lists/listinfo/fisterra-devel > -- Bruno Teixeira |
From: jfernandez <jfe...@ig...> - 2007-09-04 16:26:47
|
On Tue, Sep 04, 2007 at 01:55:43PM +0200, Antia Puentes Felpeto wrote: > Hi!, > > the problem is resolved by changing the value of the ORBIT parameter > "-ORBInitialMsgLimit" in the file: client/com/f_communication_layer.c > Great !!! Could be a good idea to add a new parameter in server_config.xml. However, i would think in a different approahc to implement your use case. I think that implement an utility service to transfer huge amount of data is not very efficient. I would try a listing based approach. What do you think ? -- Javier Fernández García-Boente Ingeniero en Informática mailto:jfe...@ig... Igalia http://www.igalia.com Telf. +34 981 91 39 91 Fax. +34 981 91 39 49 |
From: Antia P. F. <apu...@ig...> - 2007-09-04 11:56:16
|
Hi!, the problem is resolved by changing the value of the ORBIT parameter "-ORBInitialMsgLimit" in the file: client/com/f_communication_layer.c This parameter has the next meaning: "ORBInitialMsgLimit=3D# Amount of data accepted on first method invocation. Succeeding method invocations are not limited. This option is used to prevent DOS attacks - ie. opening a connection to service, sending huge amount of junk data." Thanks Chema for the information :D Regards. El lun, 03-09-2007 a las 20:06 +0200, Antia Puentes Felpeto escribi=F3: > Hi! >=20 > I have a problem with CORBA: >=20 > "No se pudo contactar con el servidor Fisterra: Unexpected communication > error, the server is up and running but there appears to have been an > error. IDL:omg.org/CORBA/COMM_FAILURE:1.0" >=20 > This error is produced when I try to send a list of 10.000 elements but > it works well for a smaller list of 5.000 elements, in detail I use the > next service for testing called: >=20 >=20 > "boolean check_corba_error_retrieving_accounts( > in unsigned long long enterprise_code,=20 > out f_data::BarnacleList account_list,=20 > in session::session_object session) raises > (f_common::FisterraException)" >=20 > that returns a list of accounts of size 10.000. >=20 > The exception appears in the method asociated in the > f_com_corba_model_delegate.c when you evaluate the condition: >=20 > result =3D !f_com_corba_handle_corba_exception_with_message("Unexpected > communication error, the server is up and running but there appears to > have been an error. ",&ev, error) && result; >=20 >=20 > Tell me if you have any idea of the cause of the problem. >=20 > Thanks! >=20 >=20 |
From: Antia P. F. <apu...@ig...> - 2007-09-03 18:07:26
|
Hi! I have a problem with CORBA: "No se pudo contactar con el servidor Fisterra: Unexpected communication error, the server is up and running but there appears to have been an error. IDL:omg.org/CORBA/COMM_FAILURE:1.0" This error is produced when I try to send a list of 10.000 elements but it works well for a smaller list of 5.000 elements, in detail I use the next service for testing called: "boolean check_corba_error_retrieving_accounts( in unsigned long long enterprise_code,=20 out f_data::BarnacleList account_list,=20 in session::session_object session) raises (f_common::FisterraException)" that returns a list of accounts of size 10.000. The exception appears in the method asociated in the f_com_corba_model_delegate.c when you evaluate the condition: result =3D !f_com_corba_handle_corba_exception_with_message("Unexpected communication error, the server is up and running but there appears to have been an error. ",&ev, error) && result; Tell me if you have any idea of the cause of the problem. Thanks! --=20 Ant=EDa Puentes Felpeto mailto:apu...@ig... Phone: +34 981 913991 Fax: +34 615 845273 Igalia http://www.igalia.com |
From: Jorge B. G. <jba...@ig...> - 2007-08-21 15:55:05
|
I'm testing fisterra-distribution in debian etch. I'm using the orbit version that came with debian etch (2.14). I start the name server with this line: orbit-name-server-2 --key=NameService -ORBIIOPIPv4=1 -ORBIIOPIPName=localhost -ORBIIOPIPSock=4444 -ORBCorbaloc=1 -ORBIIOPUNIX=0 Then I startup the fisterra2-distribution server, and everything's ok. But when I start the fisterra-session-server I get the following error: ** ERROR **: file corba-object.c: line 29 (g_CORBA_Object_hash): assertion failed: (obj->object_key != NULL) aborting... Using the name-client-2 I could see that the server registers without problems its values in the name server. Debugging I see that the fisterra-session-server can register properly the subcontext "Fisterra Store", but when inserts the final context the session-server and the name server hang, and the session server gives the error described above. I inspected the code in fisterra2-distribution-server and fisterra-session-server where they execute the bind_service function, to register its services in the name server. But they are almost equal. i don't know where the error came from. What's that key that shouldn't be NULL and where should it be set? |
From: API <api...@ig...> - 2007-08-17 16:23:38
|
> > Yes, it compares two dates, but > next_payment_date1_tm == next_payment_date2_tm > > because they are initialized with the same value > > next_payment_date1 = previous_date + money_order_days*24*3600; > next_payment_date2 = previous_date + money_order_days*24*3600; > /* next_payment_date1 == next_payment_date2 */ > localtime_r(&next_payment_date1, &next_payment_date1_tm); > localtime_r(&next_payment_date2, &next_payment_date2_tm); > /* next_payment_date1 == next_payment_date2 */ > > They are never modified, so when we get to the comparison, they are > still equal. > > The comparison > > if (abs(next_payment_date1_tm.tm_mday - payment_day) < > abs(next_payment_date2_tm.tm_mday - payment_day2)) { > > is equivalent to > > if (abs(next_payment_date1_tm.tm_mday - payment_day) < > abs(next_payment_date1_tm.tm_mday - payment_day2)) { > > because next_payment_date1_tm.tm_mday == next_payment_date2_tm.tm_mday > > And this is the only place where this structure is used, and you can > replace it for the first structure, so the second structure isn't needed > (or there are something else missing, I don't know). Hi, I'm the one who made this code. First of all, it isn't a clear code (sorry). Reviewing the code, Im agree with your final conclusion, the second next_payment_date aren't needed. You only need a computed "next day", and then compare it using payment_day and payment_day2, so a clean/clear code should be: next_payment_date = previous_date + money_order_days*24*3600; localtime_r(&next_payment_date, &next_payment_date_tm); final_time_tm.tm_sec = 0; final_time_tm.tm_min = 0; final_time_tm.tm_hour = 0; final_time_tm.tm_mon = next_payment_date_tm.tm_mon; final_time_tm.tm_year = next_payment_date_tm.tm_year; final_time_tm.tm_isdst = 0; if (abs(next_payment_date_tm.tm_mday - payment_day) < abs(next_payment_date_tm.tm_mday - payment_day2)) { final_time_tm.tm_mday = payment_day; } else { final_time_tm.tm_mday = payment_day2; } result = mktime(&final_time_tm); I suppose that this came from a previous version of this algorith that requires to structures, as I read on this comments: final_time_tm.tm_mon = next_payment_date1_tm.tm_mon; /* next_payment_date1 or next_payment_date2 */ final_time_tm.tm_year = next_payment_date1_tm.tm_year; /* next_payment_date1 or next_payment_date2 */ I think that previously I compute two dates, and then I decide one or another as the final_time_tm, but the current approach is easier, so I implement it and then (as this works) I don't remember to clean the second one. So you can try it, and if it works, you can clean the code. It is better to remove the comments too. To try it, the easier way is use fisterra-repair, creating a new invoice, and change the first payment day. === API (api...@ig...) Igalia - http://www.igalia.com - 981 91 39 91 - Fax 981 91 39 49 http://blogs.igalia.com/apinheiro |