demo server performance
Locked
123
123
 
|
small misunderstanding.
50 as business models, in realestate, education, restraunt, and so on. so this is work that has to be done even if the paritular busine3ss model has not been sold so that it is update when a clients buys. yes I have my own Svn there is "production" for each. and a script that upgrades each client for that business model that is already in production. this is nothing new to me since I have been doing software life cycles since the early 80's. ===================== BJ Freeman Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/9/2010 4:18 PM: > On 12/09/2010 06:09 PM, BJ Freeman wrote: >> You got me there Adam. >> and I am not saying we test or run upgrade at each update of 10.4. >> based on efforts so far I don't expect the effort I outlined to be done >> by the volunteers, though they are the best qualified to do this. >> >> as you see I do take my support of ofbiz seriously. >> and when you multiply this more than 50 times it turns out to be more >> than a man year to release what I consider stable systems. > > We don't upgrade production systems. We leave them alone. If there are > problems, we backport changes into whatever version of ofbiz is > deployed. For the last 3 years, that has been thru a debian package of > ofbiz. When a client has a problem, and it gets fixed, using the debian > package allows us to get that same fix out to other production instances > running the same version. > > We also manage the debian package thru git, and it's possible to > checkout the exact version of the debian package locally onto the > production system. We then change OFBIZ_HOME in the init script to point > to the checkout, and can then fix the code in place. Once the fix works, > it is copied into the build system, and a new package is produced. > > Full ofbiz package upgrades are never done without a client paying. > > I currently have ofbiz packages of 595296, 811564, and 902021 that I > have to maintain. There are some really old versions, where we would > take a snapshot of whatever ofbiz was current at the time the new job > was created, but we've moved away from that. Instead, the company as a > whole decided to stick with a version of ofbiz for an extended period. > This period tends to be yearly(but that's not set in stone). > |
|
|
In reply to this post by Jacques Le Roux
Yesterday I gave a look to the demo visits and found that Google is hitting
the server about every 30 seconds. So it is possible that any URL (includind Webtools->Artifact Info) is hitten almost frequently. -Bruno 2010/12/10 Jacques Le Roux <[hidden email]> > From: "BJ Freeman" <[hidden email]> > >> Thanks for you view on my motives. >> >> From what Jacques states the server has max hardware resources. >> so what resources are you referring to? >> I since I have a similar server running more than what Jacques has stated, >> and it runs, I am at a loss on how to work on the ofbiz demo. >> I have been focused as much as I am allowed on this for almost a year. >> considering posting five urls at the same time should not effect a server, >> I don't see that as testing the limits of the server. >> > > Which URLs? It really depends on them... Artifact Info, Entity Maintenance, > Label Manager, etc. are good culprits... This does not mean that we can't > use Entity Maintenance on the demo server, nor even Artifact Info. But it > depends on the number of people which are using them at the same time. And > when it's down, it's down: you will have to wait a good soul (not sleeping, > like me in some mins) to reload the demo instance... Webtools are not all > days tools for a production server... I will suggest to use rather such > tools locally... Does it make sense? > > Thanks > > Jacques > > > >> Scott Gray sent the following on 12/9/2010 1:47 PM: >> >>> Everybody works on the areas of the system that are important to them, I >>> suggest you do the same. >>> >>> The demo server is under-resourced so of course you're going to be able >>> to bring it down if you try to, my suggestion is that you don't try to. >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>> >>> there is a thread on the user ML about the demo being slow. >>>> I would think that would be a high priority for all those that commit >>>> and make changes to ofbiz. >>>> after all what good is all this stuff if it can't be used. >>>> I brought down the demo trunk by accessing with seperate requests at one >>>> time, as I stated on the user ml. >>>> >>>> lets focus on real problems. >>>> >>>> >>>> >>>> >>> >> > > |
Administrator
|
Yes, I have asked the infra team it they could filter spiders, but got no answers. I guess they expect us to also handle HTTPD. I
did not look at it yet Jacques From: "Bruno Busco" <[hidden email]> > Yesterday I gave a look to the demo visits and found that Google is hitting > the server about every 30 seconds. > So it is possible that any URL (includind Webtools->Artifact Info) is hitten > almost frequently. > > -Bruno > > 2010/12/10 Jacques Le Roux <[hidden email]> > >> From: "BJ Freeman" <[hidden email]> >> >>> Thanks for you view on my motives. >>> >>> From what Jacques states the server has max hardware resources. >>> so what resources are you referring to? >>> I since I have a similar server running more than what Jacques has stated, >>> and it runs, I am at a loss on how to work on the ofbiz demo. >>> I have been focused as much as I am allowed on this for almost a year. >>> considering posting five urls at the same time should not effect a server, >>> I don't see that as testing the limits of the server. >>> >> >> Which URLs? It really depends on them... Artifact Info, Entity Maintenance, >> Label Manager, etc. are good culprits... This does not mean that we can't >> use Entity Maintenance on the demo server, nor even Artifact Info. But it >> depends on the number of people which are using them at the same time. And >> when it's down, it's down: you will have to wait a good soul (not sleeping, >> like me in some mins) to reload the demo instance... Webtools are not all >> days tools for a production server... I will suggest to use rather such >> tools locally... Does it make sense? >> >> Thanks >> >> Jacques >> >> >> >>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>> >>>> Everybody works on the areas of the system that are important to them, I >>>> suggest you do the same. >>>> >>>> The demo server is under-resourced so of course you're going to be able >>>> to bring it down if you try to, my suggestion is that you don't try to. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>> >>>> there is a thread on the user ML about the demo being slow. >>>>> I would think that would be a high priority for all those that commit >>>>> and make changes to ofbiz. >>>>> after all what good is all this stuff if it can't be used. >>>>> I brought down the demo trunk by accessing with seperate requests at one >>>>> time, as I stated on the user ml. >>>>> >>>>> lets focus on real problems. >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> > |
|
|
In reply to this post by Bruno Busco
That's an interesting point, I guess because of the admin credentials being included in the links to the demos that google is able to follow on through into all the backend apps.
Regards Scott HotWax Media http://www.hotwaxmedia.com On 10/12/2010, at 10:24 PM, Bruno Busco wrote: > Yesterday I gave a look to the demo visits and found that Google is hitting > the server about every 30 seconds. > So it is possible that any URL (includind Webtools->Artifact Info) is hitten > almost frequently. > > -Bruno > > 2010/12/10 Jacques Le Roux <[hidden email]> > >> From: "BJ Freeman" <[hidden email]> >> >>> Thanks for you view on my motives. >>> >>> From what Jacques states the server has max hardware resources. >>> so what resources are you referring to? >>> I since I have a similar server running more than what Jacques has stated, >>> and it runs, I am at a loss on how to work on the ofbiz demo. >>> I have been focused as much as I am allowed on this for almost a year. >>> considering posting five urls at the same time should not effect a server, >>> I don't see that as testing the limits of the server. >>> >> >> Which URLs? It really depends on them... Artifact Info, Entity Maintenance, >> Label Manager, etc. are good culprits... This does not mean that we can't >> use Entity Maintenance on the demo server, nor even Artifact Info. But it >> depends on the number of people which are using them at the same time. And >> when it's down, it's down: you will have to wait a good soul (not sleeping, >> like me in some mins) to reload the demo instance... Webtools are not all >> days tools for a production server... I will suggest to use rather such >> tools locally... Does it make sense? >> >> Thanks >> >> Jacques >> >> >> >>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>> >>>> Everybody works on the areas of the system that are important to them, I >>>> suggest you do the same. >>>> >>>> The demo server is under-resourced so of course you're going to be able >>>> to bring it down if you try to, my suggestion is that you don't try to. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>> >>>> there is a thread on the user ML about the demo being slow. >>>>> I would think that would be a high priority for all those that commit >>>>> and make changes to ofbiz. >>>>> after all what good is all this stuff if it can't be used. >>>>> I brought down the demo trunk by accessing with seperate requests at one >>>>> time, as I stated on the user ml. >>>>> >>>>> lets focus on real problems. >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> |
smime.p7s (3K) |
|
In reply to this post by Jacques Le Roux
Just for clarity, I don't test on the ofbiz "DEmO"
server. I give links in responses to questions or ask them to run their steps on the server to make sure we are talking about the same thing. I apologize if it seems I am demanding, by letting you know what I see that is transitional most of the time. It was meant to be helpful. I really do appreciated your efforts, and please get some rest. ========================= BJ Freeman Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Jacques Le Roux sent the following on 12/9/2010 3:27 PM: > From: "BJ Freeman" <[hidden email]> >> Thanks for you view on my motives. >> From what Jacques states the server has max hardware resources. >> so what resources are you referring to? >> I since I have a similar server running more than what Jacques has >> stated, and it runs, I am at a loss on how to work on the ofbiz demo. >> I have been focused as much as I am allowed on this for almost a year. >> considering posting five urls at the same time should not effect a >> server, I don't see that as testing the limits of the server. > > Which URLs? It really depends on them... Artifact Info, Entity > Maintenance, Label Manager, etc. are good culprits... This does not mean > that we can't use Entity Maintenance on the demo server, nor even > Artifact Info. But it depends on the number of people which are using > them at the same time. And when it's down, it's down: you will have to > wait a good soul (not sleeping, like me in some mins) to reload the demo > instance... Webtools are not all days tools for a production server... I > will suggest to use rather such tools locally... Does it make sense? > > Thanks > > Jacques > >> >> Scott Gray sent the following on 12/9/2010 1:47 PM: >>> Everybody works on the areas of the system that are important to >>> them, I suggest you do the same. >>> >>> The demo server is under-resourced so of course you're going to be >>> able to bring it down if you try to, my suggestion is that you don't >>> try to. >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>> >>>> there is a thread on the user ML about the demo being slow. >>>> I would think that would be a high priority for all those that >>>> commit and make changes to ofbiz. >>>> after all what good is all this stuff if it can't be used. >>>> I brought down the demo trunk by accessing with seperate requests at >>>> one time, as I stated on the user ml. >>>> >>>> lets focus on real problems. >>>> >>>> >>>> >>> >> > > > |
|
Administrator
|
In reply to this post by Jacques Le Roux
Hi devs,
FYI, this morning the trunk demo was stale again. It was running but not accessible. I then stopped and restarted, same issue. I tried an "svn st" no issues there. I reloaded all manually (I have a script for that) and it was then OK. BJ, I tried to reload Firefox with your 5 URLs: no problems (but to enter the login/pwd couple of course). But now that I look at the demo instance it's running again at near 100% at any moment. So if nobody entered an help URL there is another process which causes the same kind of issue. I will stop to monitor this for now, as anyway it's working and I don't want to spend all my time at it. But it's really annoying to see this... Jacques From: "Jacques Le Roux" <[hidden email]> > From: "BJ Freeman" <[hidden email]> >> when I restart my client firefox brings up all the pages from last session. >> the following URl are accessed from different tabs. >> I expect them to come up to the login screen except for the ecommerce. >> many times I will get >> problem loading >> http://demo-trunk.ofbiz.apache.org:8080/ecommerce/control/main >> https://demo-trunk.ofbiz.apache.org/accounting/control/FindBillingAccount?partyId=DemoCustomer >> https://demo-trunk.ofbiz.apache.org/webtools/control/login >> https://demo-trunk.ofbiz.apache.org/partymgr/control/editpartygroup?partyId=DemoSupplier >> https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=Product&find=true&VIEW_SIZE=50&VIEW_INDEX=0 > > What kinds of problems? > >> lately when they load >> http://monitoring.apache.org/status/ >> shows everthing is ok >> I then load the above URLs and get a warning then flap then shutdown. > > With the above URLs all should go smoothly, I'm surprised... I will test tomorrow... > > Jacques > >> I can not duplicate the above on my demo-trunk on my server. >> >> ========================= >> >> BJ Freeman >> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >> Specialtymarket.com <http://www.specialtymarket.com/> >> Systems Integrator-- Glad to Assist >> >> Chat Y! messenger: bjfr33man >> >> >> Adam Heath sent the following on 12/9/2010 3:13 PM: >>> On 12/09/2010 05:01 PM, BJ Freeman wrote: >>>> Thanks for you view on my motives. >>>> From what Jacques states the server has max hardware resources. >>>> so what resources are you referring to? >>>> I since I have a similar server running more than what Jacques has >>>> stated, and it runs, I am at a loss on how to work on the ofbiz demo. >>>> I have been focused as much as I am allowed on this for almost a year. >>>> considering posting five urls at the same time should not effect a >>>> server, I don't see that as testing the limits of the server. >>> >>> What urls? What actions are you performing, and what do you expect to >>> happen? Details, please. >>> >>> 'max hardware' to me means that it has the most resources that are >>> available. It most definately does not mean that it is running on the >>> fastest computer known to man. >>> >>> Plus, it is not tuned to for its installation. Installing a production >>> system for a client requires tuning tons of different knobs. For each >>> install, those knobs will be different. It does not make sense to change >>> the sane defaults in ofbiz to something that is for one particular >>> install(apache demo installs). >>> >>> As David said, this project is just a bunch of volunteers. If you see a >>> problem, and no one steps up to resolve it(or, at the least, >>> investigate), then it falls on the reporter to do the work. If that >>> doesn't happen, then I guess nothing will be finished. But you can't >>> force anyone in this project to do anything. >>> >>> The best you could do(if I could borrow the terminology) is to show the >>> business case for why something should be better, and get others to be >>> excited about fixing it. Then you can just sit back and watch others do >>> work for you. >>> >> > |
|
Administrator
|
In reply to this post by Scott Gray-2
We currently use flexadmin as it was set before we ran on Contegix. On Contegix we used demoadmin, should we turn to it rather?
Thanks Jacques Scott Gray wrote: > That's an interesting point, I guess because of the admin credentials being included in the links to the demos that google is > able to follow on through into all the backend apps. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 10/12/2010, at 10:24 PM, Bruno Busco wrote: > >> Yesterday I gave a look to the demo visits and found that Google is hitting >> the server about every 30 seconds. >> So it is possible that any URL (includind Webtools->Artifact Info) is hitten >> almost frequently. >> >> -Bruno >> >> 2010/12/10 Jacques Le Roux <[hidden email]> >> >>> From: "BJ Freeman" <[hidden email]> >>> >>>> Thanks for you view on my motives. >>>> >>>> From what Jacques states the server has max hardware resources. >>>> so what resources are you referring to? >>>> I since I have a similar server running more than what Jacques has stated, >>>> and it runs, I am at a loss on how to work on the ofbiz demo. >>>> I have been focused as much as I am allowed on this for almost a year. >>>> considering posting five urls at the same time should not effect a server, >>>> I don't see that as testing the limits of the server. >>>> >>> >>> Which URLs? It really depends on them... Artifact Info, Entity Maintenance, >>> Label Manager, etc. are good culprits... This does not mean that we can't >>> use Entity Maintenance on the demo server, nor even Artifact Info. But it >>> depends on the number of people which are using them at the same time. And >>> when it's down, it's down: you will have to wait a good soul (not sleeping, >>> like me in some mins) to reload the demo instance... Webtools are not all >>> days tools for a production server... I will suggest to use rather such >>> tools locally... Does it make sense? >>> >>> Thanks >>> >>> Jacques >>> >>> >>> >>>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>>> >>>>> Everybody works on the areas of the system that are important to them, I >>>>> suggest you do the same. >>>>> >>>>> The demo server is under-resourced so of course you're going to be able >>>>> to bring it down if you try to, my suggestion is that you don't try to. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>>> >>>>> there is a thread on the user ML about the demo being slow. >>>>>> I would think that would be a high priority for all those that commit >>>>>> and make changes to ofbiz. >>>>>> after all what good is all this stuff if it can't be used. >>>>>> I brought down the demo trunk by accessing with seperate requests at one >>>>>> time, as I stated on the user ml. >>>>>> >>>>>> lets focus on real problems. |
Re: demo server performance
|
|
Why not just kepp out Google (and all the other search engines) with
robots.txt? Christian Jacques Le Roux schrieb: > We currently use flexadmin as it was set before we ran on Contegix. On > Contegix we used demoadmin, should we turn to it rather? > > Thanks > > Jacques > > Scott Gray wrote: >> That's an interesting point, I guess because of the admin credentials >> being included in the links to the demos that google is >> able to follow on through into all the backend apps. >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 10/12/2010, at 10:24 PM, Bruno Busco wrote: >> >>> Yesterday I gave a look to the demo visits and found that Google is >>> hitting >>> the server about every 30 seconds. >>> So it is possible that any URL (includind Webtools->Artifact Info) is >>> hitten >>> almost frequently. >>> >>> -Bruno >>> >>> 2010/12/10 Jacques Le Roux <[hidden email]> >>> >>>> From: "BJ Freeman" <[hidden email]> >>>> >>>>> Thanks for you view on my motives. >>>>> >>>>> From what Jacques states the server has max hardware resources. >>>>> so what resources are you referring to? >>>>> I since I have a similar server running more than what Jacques has >>>>> stated, >>>>> and it runs, I am at a loss on how to work on the ofbiz demo. >>>>> I have been focused as much as I am allowed on this for almost a year. >>>>> considering posting five urls at the same time should not effect a >>>>> server, >>>>> I don't see that as testing the limits of the server. >>>>> >>>> >>>> Which URLs? It really depends on them... Artifact Info, Entity >>>> Maintenance, >>>> Label Manager, etc. are good culprits... This does not mean that we >>>> can't >>>> use Entity Maintenance on the demo server, nor even Artifact Info. >>>> But it >>>> depends on the number of people which are using them at the same >>>> time. And >>>> when it's down, it's down: you will have to wait a good soul (not >>>> sleeping, >>>> like me in some mins) to reload the demo instance... Webtools are >>>> not all >>>> days tools for a production server... I will suggest to use rather such >>>> tools locally... Does it make sense? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>>>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>>>> >>>>>> Everybody works on the areas of the system that are important to >>>>>> them, I >>>>>> suggest you do the same. >>>>>> >>>>>> The demo server is under-resourced so of course you're going to be >>>>>> able >>>>>> to bring it down if you try to, my suggestion is that you don't >>>>>> try to. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> >>>>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>>>> >>>>>> there is a thread on the user ML about the demo being slow. >>>>>>> I would think that would be a high priority for all those that >>>>>>> commit >>>>>>> and make changes to ofbiz. >>>>>>> after all what good is all this stuff if it can't be used. >>>>>>> I brought down the demo trunk by accessing with seperate requests >>>>>>> at one >>>>>>> time, as I stated on the user ml. >>>>>>> >>>>>>> lets focus on real problems. > > |
|
Administrator
|
Right, that's what I would do if I knew where to put it. I tried to put one at framework/webtools/webapp/webtools
User-agent: * Disallow: / But I'm not sure it works and anyway it would cover only webtools Jacques Christian Geisert wrote: > Why not just kepp out Google (and all the other search engines) with > robots.txt? > > Christian > > Jacques Le Roux schrieb: >> We currently use flexadmin as it was set before we ran on Contegix. On >> Contegix we used demoadmin, should we turn to it rather? >> >> Thanks >> >> Jacques >> >> Scott Gray wrote: >>> That's an interesting point, I guess because of the admin credentials >>> being included in the links to the demos that google is >>> able to follow on through into all the backend apps. >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 10/12/2010, at 10:24 PM, Bruno Busco wrote: >>> >>>> Yesterday I gave a look to the demo visits and found that Google is >>>> hitting >>>> the server about every 30 seconds. >>>> So it is possible that any URL (includind Webtools->Artifact Info) is >>>> hitten >>>> almost frequently. >>>> >>>> -Bruno >>>> >>>> 2010/12/10 Jacques Le Roux <[hidden email]> >>>> >>>>> From: "BJ Freeman" <[hidden email]> >>>>> >>>>>> Thanks for you view on my motives. >>>>>> >>>>>> From what Jacques states the server has max hardware resources. >>>>>> so what resources are you referring to? >>>>>> I since I have a similar server running more than what Jacques has >>>>>> stated, >>>>>> and it runs, I am at a loss on how to work on the ofbiz demo. >>>>>> I have been focused as much as I am allowed on this for almost a year. >>>>>> considering posting five urls at the same time should not effect a >>>>>> server, >>>>>> I don't see that as testing the limits of the server. >>>>>> >>>>> >>>>> Which URLs? It really depends on them... Artifact Info, Entity >>>>> Maintenance, >>>>> Label Manager, etc. are good culprits... This does not mean that we >>>>> can't >>>>> use Entity Maintenance on the demo server, nor even Artifact Info. >>>>> But it >>>>> depends on the number of people which are using them at the same >>>>> time. And >>>>> when it's down, it's down: you will have to wait a good soul (not >>>>> sleeping, >>>>> like me in some mins) to reload the demo instance... Webtools are >>>>> not all >>>>> days tools for a production server... I will suggest to use rather such >>>>> tools locally... Does it make sense? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>>>>> >>>>>>> Everybody works on the areas of the system that are important to >>>>>>> them, I >>>>>>> suggest you do the same. >>>>>>> >>>>>>> The demo server is under-resourced so of course you're going to be >>>>>>> able >>>>>>> to bring it down if you try to, my suggestion is that you don't >>>>>>> try to. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> HotWax Media >>>>>>> http://www.hotwaxmedia.com >>>>>>> >>>>>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>>>>> >>>>>>> there is a thread on the user ML about the demo being slow. >>>>>>>> I would think that would be a high priority for all those that >>>>>>>> commit >>>>>>>> and make changes to ofbiz. >>>>>>>> after all what good is all this stuff if it can't be used. >>>>>>>> I brought down the demo trunk by accessing with seperate requests >>>>>>>> at one >>>>>>>> time, as I stated on the user ml. >>>>>>>> >>>>>>>> lets focus on real problems. |
|
Administrator
|
In reply to this post by BJ Freeman
Thanks BJ,
I will remember. Unfortunaltely for the (less annoying) problem at hand we need more a detailled threads report and have nothing ready. Jacques BJ Freeman wrote: > that works for me. Count me in. > > ========================= > BJ Freeman > Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> > Specialtymarket.com <http://www.specialtymarket.com/> > Systems Integrator-- Glad to Assist > > Chat Y! messenger: bjfr33man > > > Jacques Le Roux sent the following on 12/9/2010 3:42 PM: >> From: "Adam Heath" <[hidden email]> >>> On 12/09/2010 05:18 PM, Jacques Le Roux wrote: >>>> I have spent a lot of time (I mean in respect of my free time) this last >>>> days to understand the problems. >>>> It appears that removing the help was a great relief for our demo sever. >>>> >>>> For few hours now we are running with >>>> >>>> trunk: -Xms128M -Xmx768M -XX:MaxPermSize=192m (so max seems >>>> 768+192=960MB but actually it's more) >>>> branch9: -Xms128M -Xmx512M >>>> >>>> For instance now we have >>>> Mem: 2573924k total, 2159888k used, 414036k free, 53672k buffers >>>> Swap: 1502036k total, 50676k used, 1451360k free, 438000k cached >>>> >>>> PID USER PR NI VIRT RES SHR %CPU %MEM >>>> trunk 14896 ofbiz 20 0 1377m 753m 7956 0.3 30.0 >>>> branch9 18147 ofbiz 20 0 918m 670m 13m 0.7 26.7 >>>> >>>> As you can see at some stage we reach more than 960MB for the trunk >>>> (1377 max, which is approx but anyway) >>>> >>>> The main points: >>>> * We have still around 400MB free, but I suppose it will be less just >>>> before the 24h reload) >>>> * We have anymore CPU running always near 100%, for instance right now >>>> PID USER PR NI VIRT RES SHR %CPU %MEM TIME+ COMMAND >>>> 14896 ofbiz 20 0 1377m 757m 7968 29.7 30.2 19:57.63 java -Xms128M >>>> -Xmx768M -XX:MaxPermSize=192m >>>> 18147 ofbiz 20 0 918m 671m 13m 22.4 26.7 14:23.55 java -Xms128M -Xmx512M >>>> >>>> >>>> I will wait some days and, if things continue to go well, will re-use >>>> more memory for our 2 processes. But I know there are other >>>> problems... >>>> >>>> Like David and Scott said if people are using the Artifact Info or other >>>> gluttonous features (Birts?) we will be in trouble with our >>>> memory quota. So if such things come back in the future I will suggest >>>> to prevent users to use them on the demo server... >>>> >>>> For the real problems, I think we should focus on fixing the online Help >>>> feature. It seems that this isues is something relatively >>>> new and a disect should help (I use this word because it's convenient, >>>> on my side I simply use dichotomic tests with svn but I have >>>> bigger fish to fry for now, that's why I have deactivated it). I think >>>> it's not more than few days (weeks?), help appreciated... >>> >>> Hate to disappoint, but all those memory stats you posted are >>> completely useless for actually tracking down what java is doing. >>> >>> You need to become friends with jmap, jhat(both standard jdk tools), >>> and ibm's heap analyzer. Plus, sending the QUIT signal to the java >>> process. >> >> Yes I know, this is only to give a general information about what's >> going on on the server. >> As I have already wrote I'm actually using mat >> http://www.eclipse.org/mat/ behind the scene >> I'm also using -XX:+HeapDumpOnOutOfMemoryError but most of the time get >> rather out of swap issues when crashing, hard to trace... >> One way would be mod_log_forensic... if someone wants to help... >> >>> In all honesty, I'm going to go out on a limb here and say the higher >>> memory requirements of newer ofbiz is due to converting tons of code >>> to groovy. With it as a simple-method, or a bsh, both would end up >>> using heap, as they are interpetted. java or groovy get compiled to >>> bytecode, which ends up being allocated in the permgen area, which >>> might also get jit compiled. So, permgen needs to increase. >> >> It does not seem that we have permgen issues. It's not yet clear, but >> for those interested I could move hprof files from demo roots to >> bigfiles dir... >> >> Thanks >> >> Jacques |
Re: demo server performance
|
|
In reply to this post by Jacques Le Roux
Why just webtools, I think indexing the whole demo instance doesn't make
sense... I'm happy to help here (I might even find some time on the weekend ;-) Christian Jacques Le Roux schrieb: > Right, that's what I would do if I knew where to put it. I tried to put > one at framework/webtools/webapp/webtools > > User-agent: * > Disallow: / > > But I'm not sure it works and anyway it would cover only webtools > > Jacques > > Christian Geisert wrote: >> Why not just kepp out Google (and all the other search engines) with >> robots.txt? >> >> Christian >> >> Jacques Le Roux schrieb: >>> We currently use flexadmin as it was set before we ran on Contegix. On >>> Contegix we used demoadmin, should we turn to it rather? >>> >>> Thanks >>> >>> Jacques >>> >>> Scott Gray wrote: >>>> That's an interesting point, I guess because of the admin credentials >>>> being included in the links to the demos that google is >>>> able to follow on through into all the backend apps. >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 10/12/2010, at 10:24 PM, Bruno Busco wrote: >>>> >>>>> Yesterday I gave a look to the demo visits and found that Google is >>>>> hitting >>>>> the server about every 30 seconds. >>>>> So it is possible that any URL (includind Webtools->Artifact Info) is >>>>> hitten >>>>> almost frequently. >>>>> >>>>> -Bruno >>>>> >>>>> 2010/12/10 Jacques Le Roux <[hidden email]> >>>>> >>>>>> From: "BJ Freeman" <[hidden email]> >>>>>> >>>>>>> Thanks for you view on my motives. >>>>>>> >>>>>>> From what Jacques states the server has max hardware resources. >>>>>>> so what resources are you referring to? >>>>>>> I since I have a similar server running more than what Jacques has >>>>>>> stated, >>>>>>> and it runs, I am at a loss on how to work on the ofbiz demo. >>>>>>> I have been focused as much as I am allowed on this for almost a >>>>>>> year. >>>>>>> considering posting five urls at the same time should not effect a >>>>>>> server, >>>>>>> I don't see that as testing the limits of the server. >>>>>>> >>>>>> >>>>>> Which URLs? It really depends on them... Artifact Info, Entity >>>>>> Maintenance, >>>>>> Label Manager, etc. are good culprits... This does not mean that we >>>>>> can't >>>>>> use Entity Maintenance on the demo server, nor even Artifact Info. >>>>>> But it >>>>>> depends on the number of people which are using them at the same >>>>>> time. And >>>>>> when it's down, it's down: you will have to wait a good soul (not >>>>>> sleeping, >>>>>> like me in some mins) to reload the demo instance... Webtools are >>>>>> not all >>>>>> days tools for a production server... I will suggest to use rather >>>>>> such >>>>>> tools locally... Does it make sense? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>>>>>> >>>>>>>> Everybody works on the areas of the system that are important to >>>>>>>> them, I >>>>>>>> suggest you do the same. >>>>>>>> >>>>>>>> The demo server is under-resourced so of course you're going to be >>>>>>>> able >>>>>>>> to bring it down if you try to, my suggestion is that you don't >>>>>>>> try to. >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> HotWax Media >>>>>>>> http://www.hotwaxmedia.com >>>>>>>> >>>>>>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>>>>>> >>>>>>>> there is a thread on the user ML about the demo being slow. >>>>>>>>> I would think that would be a high priority for all those that >>>>>>>>> commit >>>>>>>>> and make changes to ofbiz. >>>>>>>>> after all what good is all this stuff if it can't be used. >>>>>>>>> I brought down the demo trunk by accessing with seperate requests >>>>>>>>> at one >>>>>>>>> time, as I stated on the user ml. >>>>>>>>> >>>>>>>>> lets focus on real problems. > > |
|
Administrator
|
Christian Geisert wrote:
> Why just webtools, I think indexing the whole demo instance doesn't make > sense... Yes, it's just that I'm not quite sure where to put the robots.txt (under all wepbapps roots?). That's why I spoke about HTTPD conf. I remember having handled robots there for a client site > I'm happy to help here (I might even find some time on the weekend ;-) You are welcome, but do you have an access? Else you might ask infra... Thanks Jacques > Christian > > Jacques Le Roux schrieb: >> Right, that's what I would do if I knew where to put it. I tried to put >> one at framework/webtools/webapp/webtools >> >> User-agent: * >> Disallow: / >> >> But I'm not sure it works and anyway it would cover only webtools >> >> Jacques >> >> Christian Geisert wrote: >>> Why not just kepp out Google (and all the other search engines) with >>> robots.txt? >>> >>> Christian >>> >>> Jacques Le Roux schrieb: >>>> We currently use flexadmin as it was set before we ran on Contegix. On >>>> Contegix we used demoadmin, should we turn to it rather? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> Scott Gray wrote: >>>>> That's an interesting point, I guess because of the admin credentials >>>>> being included in the links to the demos that google is >>>>> able to follow on through into all the backend apps. >>>>> Regards >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> On 10/12/2010, at 10:24 PM, Bruno Busco wrote: >>>>> >>>>>> Yesterday I gave a look to the demo visits and found that Google is >>>>>> hitting >>>>>> the server about every 30 seconds. >>>>>> So it is possible that any URL (includind Webtools->Artifact Info) is >>>>>> hitten >>>>>> almost frequently. >>>>>> >>>>>> -Bruno >>>>>> >>>>>> 2010/12/10 Jacques Le Roux <[hidden email]> >>>>>> >>>>>>> From: "BJ Freeman" <[hidden email]> >>>>>>> >>>>>>>> Thanks for you view on my motives. >>>>>>>> >>>>>>>> From what Jacques states the server has max hardware resources. >>>>>>>> so what resources are you referring to? >>>>>>>> I since I have a similar server running more than what Jacques has >>>>>>>> stated, >>>>>>>> and it runs, I am at a loss on how to work on the ofbiz demo. >>>>>>>> I have been focused as much as I am allowed on this for almost a >>>>>>>> year. >>>>>>>> considering posting five urls at the same time should not effect a >>>>>>>> server, >>>>>>>> I don't see that as testing the limits of the server. >>>>>>>> >>>>>>> >>>>>>> Which URLs? It really depends on them... Artifact Info, Entity >>>>>>> Maintenance, >>>>>>> Label Manager, etc. are good culprits... This does not mean that we >>>>>>> can't >>>>>>> use Entity Maintenance on the demo server, nor even Artifact Info. >>>>>>> But it >>>>>>> depends on the number of people which are using them at the same >>>>>>> time. And >>>>>>> when it's down, it's down: you will have to wait a good soul (not >>>>>>> sleeping, >>>>>>> like me in some mins) to reload the demo instance... Webtools are >>>>>>> not all >>>>>>> days tools for a production server... I will suggest to use rather >>>>>>> such >>>>>>> tools locally... Does it make sense? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Scott Gray sent the following on 12/9/2010 1:47 PM: >>>>>>>> >>>>>>>>> Everybody works on the areas of the system that are important to >>>>>>>>> them, I >>>>>>>>> suggest you do the same. >>>>>>>>> >>>>>>>>> The demo server is under-resourced so of course you're going to be >>>>>>>>> able >>>>>>>>> to bring it down if you try to, my suggestion is that you don't >>>>>>>>> try to. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> HotWax Media >>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>> >>>>>>>>> On 10/12/2010, at 10:32 AM, BJ Freeman wrote: >>>>>>>>> >>>>>>>>> there is a thread on the user ML about the demo being slow. >>>>>>>>>> I would think that would be a high priority for all those that >>>>>>>>>> commit >>>>>>>>>> and make changes to ofbiz. >>>>>>>>>> after all what good is all this stuff if it can't be used. >>>>>>>>>> I brought down the demo trunk by accessing with seperate requests >>>>>>>>>> at one >>>>>>>>>> time, as I stated on the user ml. >>>>>>>>>> >>>>>>>>>> lets focus on real problems. |
Re: demo server performance
|
|
Jacques Le Roux schrieb:
> Christian Geisert wrote: >> Why just webtools, I think indexing the whole demo instance doesn't make >> sense... > > Yes, it's just that I'm not quite sure where to put the robots.txt > (under all wepbapps roots?). That's why I spoke about HTTPD conf. I > remember having handled robots there for a client site > >> I'm happy to help here (I might even find some time on the weekend ;-) > > You are welcome, but do you have an access? Else you might ask infra... I have no access yet, will check out. Christian |
|
Administrator
|
In reply to this post by Jacques Le Roux
I have just tried to use top and jstack to get more information
Top gives me (using shift-H to get threads showing and c to see which thread belongs to which process) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20059 ofbiz 20 0 1398m 898m 16m R 28.4 35.7 86:07.44 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 20057 ofbiz 20 0 1398m 898m 16m R 27.8 35.7 80:37.55 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 22410 ofbiz 20 0 1398m 898m 16m R 27.8 35.7 78:17.94 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 19476 ofbiz 20 0 1398m 898m 16m S 11.4 35.7 35:27.61 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 20369 ofbiz 20 0 1398m 898m 16m R 4.2 35.7 0:19.19 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 19491 ofbiz 20 0 1398m 898m 16m S 0.3 35.7 0:20.30 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 19592 ofbiz 20 0 1398m 898m 16m S 0.3 35.7 0:01.08 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja 19826 ofbiz 20 0 1398m 898m 16m R 0.3 35.7 0:05.84 java -Xms128M -Xmx768M -XX:MaxPermSize=192m -XX:+HeapDumpOnOutOfMemoryError -Dofbiz.admin.port=10523 -Dofbiz.admin.key=so3du5kasd5dn -jar ofbiz.ja These are all trunk threads, but jstack gives me tons of this for each java thread (more than 100 threads per PID) of 20059, 20057 and 22410 $ jstack -F 20057 Attaching to process ID 20057, please wait... Debugger attached successfully. Server compiler detected. JVM version is 17.1-b03 Deadlock Detection: No deadlocks found. Thread 17347: (state = BLOCKED) Error occurred during stack walking: sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:466) at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65) at sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(LinuxAMD64JavaThreadPDAccess.java:92) at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:256) at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:218) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:76) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.tools.jstack.JStack.runJStackTool(JStack.java:118) at sun.tools.jstack.JStack.main(JStack.java:84) So, as I can't nothing with this, I tried to kill the 3 PIDS but it kills all the process I reloaded and gave up, for now it's clean Jacques From: "Jacques Le Roux" <[hidden email]> > Thanks BJ, > > I will remember. Unfortunaltely for the (less annoying) problem at hand we need more a detailled threads report and have nothing > ready. > > Jacques > > BJ Freeman wrote: >> that works for me. Count me in. >> >> ========================= >> BJ Freeman >> Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >> Specialtymarket.com <http://www.specialtymarket.com/> >> Systems Integrator-- Glad to Assist >> >> Chat Y! messenger: bjfr33man >> >> >> Jacques Le Roux sent the following on 12/9/2010 3:42 PM: >>> From: "Adam Heath" <[hidden email]> >>>> On 12/09/2010 05:18 PM, Jacques Le Roux wrote: >>>>> I have spent a lot of time (I mean in respect of my free time) this last >>>>> days to understand the problems. >>>>> It appears that removing the help was a great relief for our demo sever. >>>>> >>>>> For few hours now we are running with >>>>> >>>>> trunk: -Xms128M -Xmx768M -XX:MaxPermSize=192m (so max seems >>>>> 768+192=960MB but actually it's more) >>>>> branch9: -Xms128M -Xmx512M >>>>> >>>>> For instance now we have >>>>> Mem: 2573924k total, 2159888k used, 414036k free, 53672k buffers >>>>> Swap: 1502036k total, 50676k used, 1451360k free, 438000k cached >>>>> >>>>> PID USER PR NI VIRT RES SHR %CPU %MEM >>>>> trunk 14896 ofbiz 20 0 1377m 753m 7956 0.3 30.0 >>>>> branch9 18147 ofbiz 20 0 918m 670m 13m 0.7 26.7 >>>>> >>>>> As you can see at some stage we reach more than 960MB for the trunk >>>>> (1377 max, which is approx but anyway) >>>>> >>>>> The main points: >>>>> * We have still around 400MB free, but I suppose it will be less just >>>>> before the 24h reload) >>>>> * We have anymore CPU running always near 100%, for instance right now >>>>> PID USER PR NI VIRT RES SHR %CPU %MEM TIME+ COMMAND >>>>> 14896 ofbiz 20 0 1377m 757m 7968 29.7 30.2 19:57.63 java -Xms128M >>>>> -Xmx768M -XX:MaxPermSize=192m >>>>> 18147 ofbiz 20 0 918m 671m 13m 22.4 26.7 14:23.55 java -Xms128M -Xmx512M >>>>> >>>>> >>>>> I will wait some days and, if things continue to go well, will re-use >>>>> more memory for our 2 processes. But I know there are other >>>>> problems... >>>>> >>>>> Like David and Scott said if people are using the Artifact Info or other >>>>> gluttonous features (Birts?) we will be in trouble with our >>>>> memory quota. So if such things come back in the future I will suggest >>>>> to prevent users to use them on the demo server... >>>>> >>>>> For the real problems, I think we should focus on fixing the online Help >>>>> feature. It seems that this isues is something relatively >>>>> new and a disect should help (I use this word because it's convenient, >>>>> on my side I simply use dichotomic tests with svn but I have >>>>> bigger fish to fry for now, that's why I have deactivated it). I think >>>>> it's not more than few days (weeks?), help appreciated... >>>> >>>> Hate to disappoint, but all those memory stats you posted are >>>> completely useless for actually tracking down what java is doing. >>>> >>>> You need to become friends with jmap, jhat(both standard jdk tools), >>>> and ibm's heap analyzer. Plus, sending the QUIT signal to the java >>>> process. >>> >>> Yes I know, this is only to give a general information about what's >>> going on on the server. >>> As I have already wrote I'm actually using mat >>> http://www.eclipse.org/mat/ behind the scene >>> I'm also using -XX:+HeapDumpOnOutOfMemoryError but most of the time get >>> rather out of swap issues when crashing, hard to trace... >>> One way would be mod_log_forensic... if someone wants to help... >>> >>>> In all honesty, I'm going to go out on a limb here and say the higher >>>> memory requirements of newer ofbiz is due to converting tons of code >>>> to groovy. With it as a simple-method, or a bsh, both would end up >>>> using heap, as they are interpetted. java or groovy get compiled to >>>> bytecode, which ends up being allocated in the permgen area, which >>>> might also get jit compiled. So, permgen needs to increase. >>> >>> It does not seem that we have permgen issues. It's not yet clear, but >>> for those interested I could move hprof files from demo roots to >>> bigfiles dir... >>> >>> Thanks >>> >>> Jacques > > |
|
|
In reply to this post by Jacques Le Roux
On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
> Hi devs, > > FYI, this morning the trunk demo was stale again. It was running but not > accessible. I then stopped and restarted, same issue. I tried an "svn > st" no issues there. I reloaded all manually (I have a script for that) > and it was then OK. When these issues occur, send QUIT to the java process; it'll give you a stack dump, and a memory usage summary. Then, use jmap to get a binary heap dump. Those 2 things will allow for debugging this. Also keep track of which particular svn version the system is running. |
|
|
In reply to this post by Jacques Le Roux
On 12/10/2010 07:20 AM, Jacques Le Roux wrote:
> Christian Geisert wrote: >> Why just webtools, I think indexing the whole demo instance doesn't make >> sense... > > Yes, it's just that I'm not quite sure where to put the robots.txt > (under all wepbapps roots?). That's why I spoke about HTTPD conf. I > remember having handled robots there for a client site robots.txt must go at the root of the server, ie, /. We don't want to keep google(or anything else) from indexing any of the demos. It's useful to have them point to us. What we do want, is to preclude certain urls that cause things to fall over. Or, maybe those certain things should not be enabled by default. Maybe move them to a specialpurpose location, which then extends the framework/application components with additional menu/screen entries. |
|
Administrator
|
From: "Adam Heath" <[hidden email]>
> On 12/10/2010 07:20 AM, Jacques Le Roux wrote: >> Christian Geisert wrote: >>> Why just webtools, I think indexing the whole demo instance doesn't make >>> sense... >> >> Yes, it's just that I'm not quite sure where to put the robots.txt >> (under all wepbapps roots?). That's why I spoke about HTTPD conf. I >> remember having handled robots there for a client site > > robots.txt must go at the root of the server, ie, /. I'm not quite sure were is the root of the server. I tried OFBiz root and also (and rather) as I found <<ServerRoot "/etc/apache2">> in /etc/apache2/apache2.conf put one there also. > We don't want to keep google(or anything else) from indexing any of the demos. It's useful to have them point to us. What we do > want, is to preclude certain urls that cause things to fall over. > > Or, maybe those certain things should not be enabled by default. Maybe move them to a specialpurpose location, which then extends > the framework/application components with additional menu/screen entries. Mmm... Jacques |
|
Administrator
|
In reply to this post by Adam Heath-2
From: "Adam Heath" <[hidden email]>
> On 12/10/2010 04:05 AM, Jacques Le Roux wrote: >> Hi devs, >> >> FYI, this morning the trunk demo was stale again. It was running but not >> accessible. I then stopped and restarted, same issue. I tried an "svn >> st" no issues there. I reloaded all manually (I have a script for that) >> and it was then OK. > > When these issues occur, send QUIT to the java process; it'll give you > a stack dump, and a memory usage summary. Then, use jmap to get a > binary heap dump. Those 2 things will allow for debugging this. Also > keep track of which particular svn version the system is running. I will try that Jacques |
|
|
In reply to this post by Adam Heath-2
>
> > Or, maybe those certain things should not be enabled by default. Maybe move > them to a specialpurpose location, which then extends the > framework/application components with additional menu/screen entries. > We could also manage a patch committed to the SVN that is used for the demo server. The patch should be applied on the demo only and disable whatever we like. -Bruno |
|
|
On 12/10/2010 12:40 PM, Bruno Busco wrote:
>> >> >> Or, maybe those certain things should not be enabled by default. Maybe move >> them to a specialpurpose location, which then extends the >> framework/application components with additional menu/screen entries. >> > > We could also manage a patch committed to the SVN that is used for the demo > server. > The patch should be applied on the demo only and disable whatever we like. Sure, having a patch applied after a checkout is good. But that patch would have to be updated as svn changes; this is bad. The urls we are discussing generally wouldn't be useful in a production environment, but you would want them during development. This goes for everyone who would be wanting to use ofbiz, then eventuatlly deploy. So, a general purpose solution should be designed, not a one-off that is only used by the demo instances. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |