Re: demo server performance
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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: jquey
Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Created: (OFBIZ-4053) Implement an Entity Query Builder
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a succession
of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE, EntityFindOptions.CONCUR_READ_ONLY,
true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing and
I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept having
trouble remembering what it was called when converting some delegator calls
over. It also requires a little more typing (16-17 characters vs. 12-13), not
a big deal but every little bit helps with what would be a very commonly used
class.
- I'm struggling to see the point of having the GenericQueryBuilder interface,
the two classes share very little in the way of API and its use seems a little
superfluous to me.
Opinions on the above points or anything else to do with the implementation are
most welcome. I'd like to get the API locked down (and hopefully some javadocs
in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-4053:
--
Attachment: builder.patch
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: demo server performance
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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 Description: S/MIME cryptographic signature
Re: findByAnd(Map) ws findList(EntityCondition)
HotWax Media
http://www.hotwaxmedia.com
On 10/12/2010, at 8:58 AM, Scott Gray wrote:
On 10/12/2010, at 8:54 AM, Adam Heath wrote:
On 12/09/2010 01:48 PM, Scott Gray wrote:
On 10/12/2010, at 5:53 AM, Adam Heath wrote:
On 12/09/2010 12:03 AM, Scott Gray wrote:
On 9/12/2010, at 11:50 AM, Adam Heath wrote:
On 12/08/2010 03:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However, I'm
now starting to lean towards replacing with findList instead.
However, in my opinion, I think that will make programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead of an
EntityCondition. Without this new variant, there would be ton of
variants that would only need to import EntityCondition, just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map, doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little more than
UtilMisc. In addition to the iteration over the array, it also does a
check on the value for Comparable/Serializable. This latter check
seems a bit superfluous, as eventually the base condition classes
check the values against the model.
So, from a purist stand point, even tho findByAnd could be replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.
This reminded me of the query objects with method chaining that I
suggested a while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache(Content,
UtilMisc.toMap(contentId, assocContentId));
// becomes
thisContent =
EntityOne.query(delegator).from(Content).where(contentId,
assocContentId).cache().find();
api:
EntityOne(delegator).from()
in foo.groovy:
use(DelegatorCategory) {
}
class DelegatorCategory {
public static EntityOneBuilder EntityOne(Delegator delegator) {
return new EntityOneBuilder(delegator);
}
}
class EntityOneBuilder {
public EntityOneBuilder from(String entityName) {
return this;
}
public GenericValue query() {
return delegator.findOne();
}
}
This is almost like what you suggested, but it removes the query()
method that starts thte builder, and changes the find() to query().
EntityList would be done the same one.
The way you have it, is that the start(EntityOne, EntityList) and the
end(find(), list()), are 2 things that have to be remembered. My
version just has one thing(the start of the call).
This is all groovy DSL related though right? I hadn't worried about
groovy too much because I knew we had a fair bit of flexibility thanks to
the language features. The API I've written to date was solely intended
for java development but seems succinct enough that not much would need
to change for groovy.
Also EntityList's execute methods so far are:
list()
iterator()
first()
count()
All primary methods should be query(), imho.
interface GenericQueryBuilderT {
T query();
}
public class EntityOne implements GenericQueryBuilderGenericValue {
public GenericValue query() {}
}
public class EntityList implements
GenericQueryBuilderListGenericValue, IterableGenericValue {
public ListGenericValue query() {}
public IteratorGenericValue iterator() {}
...
}
I'm not opposed to that, but I'll need another method name for specifying
the delegator. How about use(delegator)?
public final class EntityBuilderUtil {
public static EntityOne one(Delegator delegator) {
return new EntityOne(delegator);
}
public static EntityList list(Delegator delegator) {
return new EntityList(delegator);
}
}
This also means that java api code only needs to import one class. Plus, if
this class is used as a groovy category, then groovy code can do this:
one(delegator).cache(true).
As groovy will see one as a method call, taking a variable with type
Delegator, and search all its categories to find a matching method. You'll
get all things for free.
Works for me.
Thanks
Scott
Patch attached to https://issues.apache.org/jira/browse/OFBIZ-4053
Regards
Scott
smime.p7s
Description: S/MIME cryptographic signature
Re: demo server performance
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 bjf...@free-man.net 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
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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=Productfind=trueVIEW_SIZE=50VIEW_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.
Re: demo server performance
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 bruno.bu...@gmail.com 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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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.
[jira] Commented: (OFBIZ-4051) i18n for elrte editor
[ https://issues.apache.org/jira/browse/OFBIZ-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970117#action_12970117 ] Sascha Rodekamp commented on OFBIZ-4051: Thanks Erwan for you're effort :-) i18n for elrte editor - Key: OFBIZ-4051 URL: https://issues.apache.org/jira/browse/OFBIZ-4051 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Affects Versions: jQuery Reporter: Erwan de FERRIERES Assignee: Erwan de FERRIERES Priority: Minor Fix For: jQuery Attachments: elrte_i18n.patch, elrte_i18n.zip elrte editor has its i18n files included in the archive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: demo server performance
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970128#action_12970128 ] Jacques Le Roux commented on OFBIZ-4052: Hi BJ, Looks nice indeed. I guess you don't use really the last trunk version, because I just retried with a totally clean instanec and I can't get this URL working, not the help button Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: demo server performance
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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
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 doo...@brainfood.com 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
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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
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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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.
[jira] Issue Comment Edited: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970128#action_12970128 ] Jacques Le Roux edited comment on OFBIZ-4052 at 12/10/10 8:23 AM: -- Hi BJ, Looks nice indeed. I guess you don't use really the last trunk version, because I just retried with a totally clean instanec and I can't get this URL working, nor the help button was (Author: jacques.le.roux): Hi BJ, Looks nice indeed. I guess you don't use really the last trunk version, because I just retried with a totally clean instanec and I can't get this URL working, not the help button Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
Re: findByAnd(Map) ws findList(EntityCondition)
In the spirit of changing the entity/delegator interface more object friendly,
why not take this to then next step and generate POJO interfaces for each
entity. These would extend GenericValue but provide a simple gettor/settor
facade allowing compile time type checking and removing of the string code
for much of the business logic written in java.
We have done such a thing (again in our forked application), and it makes the
Java code much more readable and easier to use. The general structure is
public class Person extends AbstractGenericValuePerson
{
public static final String ENTITY = Person;
// constructor, only called from makeValue, MUST be associated with a
delegator
protected Person(Delegator delegator) {...}
// factory method
public static Person newInstance(Delegator delegator) {...}
// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String partyId){...}
// getter and settors
public String getFirstName() {
return getString(firstName);
}
public Person setFirstName(String value) {
set(firstName, value);
return this;
}
// relationships
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws GenericEntityException{...}
}
This allows code that is much easier to debug and less error prone.. example
below is for navigating orders.
OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);
// get the orderItems
ListOrderItem orderItems = orderHeader.getOrderItemList();
BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {
totalQuantity = totalQuantity.add(orderItem.getQuantity());
}
I know we want to encourage business logic in minlang, etc... but if it is
written in java, and there is a LOT of code in java, shopping cart, etc...
this makes that code MUST more readable and maintainable. The binding between
the entity model and the java implementation can be caught as a compile time
error... significantly lowers the maintenance cost of the code.
This may be pushing a rope, but we use this ALL the time for our groovy and
java code. (would also apply to jsp code obviously). Minilang code can be type
checked by the reader... (want to check for static errors in code, without the
need to run the code).
We have implemented the generators, and the refactoring/abstracting to enable
this. We find it works great and doesn't break ANY of the nice ofbiz extend
entity semantics, etc Of course if you extend an entity and then want java
business logic to use it... you need to access those items either with
strings as stock ofbiz, or redo an entity-gen. But if there is no java code
using the entities, no need to auto-gen.
As another note, we have done a similar thing with the service interface as
you might have guessed, we're a fan of ofbiz extensibility, but NOT on how it
encourages poor Java implementation practices. (String object references,
non-type safe, public static methods everywhere etc...)
Marc
- Original Message -
On 10/12/2010, at 8:54 AM, Adam Heath wrote:
On 12/09/2010 01:48 PM, Scott Gray wrote:
On 10/12/2010, at 5:53 AM, Adam Heath wrote:
On 12/09/2010 12:03 AM, Scott Gray wrote:
On 9/12/2010, at 11:50 AM, Adam Heath wrote:
On 12/08/2010 03:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a
variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However,
I'm now starting to lean towards replacing with findList
instead. However, in my opinion, I think that will make
programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead
of an
EntityCondition. Without this new variant, there would be ton
of variants that would only need to import EntityCondition,
just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map,
doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little
more than
UtilMisc. In addition to the iteration over the array, it also
does a
check on the value for Comparable/Serializable. This latter
check seems a bit superfluous, as eventually the base
condition classes
check the values against the model.
So, from a purist stand point, even tho findByAnd could be
replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.
This reminded me of the query objects with method chaining that
I suggested a while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache(Content,
O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
I have thought about this idea, and at first glance it seems cool and
all, but one of the selling points of OFBiz is that it intentionally
stays away from this type of Object-Relational mapping. OFBiz
developers find that direct access to the relational database is easier
to use.
-Adrian
On 12/10/2010 7:20 AM, Marc Morin wrote:
In the spirit of changing the entity/delegator interface more object friendly, why not
take this to then next step and generate POJO interfaces for each entity. These would
extend GenericValue but provide a simple gettor/settor facade allowing compile time type
checking and removing of the string code for much of the business logic
written in java.
We have done such a thing (again in our forked application), and it makes the
Java code much more readable and easier to use. The general structure is
public class Person extends AbstractGenericValuePerson
{
public static final String ENTITY = Person;
// constructor, only called from makeValue, MUST be associated with a
delegator
protected Person(Delegator delegator) {...}
// factory method
public static Person newInstance(Delegator delegator) {...}
// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String partyId){...}
// getter and settors
public String getFirstName() {
return getString(firstName);
}
public Person setFirstName(String value) {
set(firstName, value);
return this;
}
// relationships
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws GenericEntityException{...}
}
This allows code that is much easier to debug and less error prone.. example
below is for navigating orders.
OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);
// get the orderItems
ListOrderItem orderItems = orderHeader.getOrderItemList();
BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {
totalQuantity = totalQuantity.add(orderItem.getQuantity());
}
I know we want to encourage business logic in minlang, etc... but if it is
written in java, and there is a LOT of code in java, shopping cart, etc...
this makes that code MUST more readable and maintainable. The binding between
the entity model and the java implementation can be caught as a compile time
error... significantly lowers the maintenance cost of the code.
This may be pushing a rope, but we use this ALL the time for our groovy and java code.
(would also apply to jsp code obviously). Minilang code can be type checked by the
reader... (want to check for static errors in code, without the need to run
the code).
We have implemented the generators, and the refactoring/abstracting to enable this. We
find it works great and doesn't break ANY of the nice ofbiz extend entity semantics,
etc Of course if you extend an entity and then want java business logic to use it...
you need to access those items either with strings as stock ofbiz, or redo an
entity-gen. But if there is no java code using the entities, no need to auto-gen.
As another note, we have done a similar thing with the service interface as you might
have guessed, we're a fan of ofbiz extensibility, but NOT on how it encourages poor Java
implementation practices. (String object references, non-type safe, public
static methods everywhere etc...)
Marc
Re: demo server performance
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 %MEMTIME+ 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 jacques.le.r...@les7arts.com 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 doo...@brainfood.com 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
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970214#action_12970214
]
Adam Heath commented on OFBIZ-4053:
---
Maybe have a few static methods in Delegator, like this:
Delegator.list(delegator).where().cache().
Also, why not add several where() variants, that mirror those in
EntityCondition(and EntityFieldMap)?
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: demo server performance
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.
Re: demo server performance
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.
Re: demo server performance
From: Adam Heath doo...@brainfood.com 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
Re: demo server performance
From: Adam Heath doo...@brainfood.com 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
Re: findByAnd(Map) ws findList(EntityCondition)
make ofbiz more object friendly goes against the orginal design and
David has address why.
=
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
Marc Morin sent the following on 12/10/2010 7:20 AM:
In the spirit of changing the entity/delegator interface more object friendly, why not
take this to then next step and generate POJO interfaces for each entity. These would
extend GenericValue but provide a simple gettor/settor facade allowing compile time type
checking and removing of the string code for much of the business logic
written in java.
We have done such a thing (again in our forked application), and it makes the
Java code much more readable and easier to use. The general structure is
public class Person extends AbstractGenericValuePerson
{
public static final String ENTITY = Person;
// constructor, only called from makeValue, MUST be associated with a
delegator
protected Person(Delegator delegator) {...}
// factory method
public static Person newInstance(Delegator delegator) {...}
// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String partyId){...}
// getter and settors
public String getFirstName() {
return getString(firstName);
}
public Person setFirstName(String value) {
set(firstName, value);
return this;
}
// relationships
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws GenericEntityException{...}
}
This allows code that is much easier to debug and less error prone.. example
below is for navigating orders.
OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);
// get the orderItems
ListOrderItem orderItems = orderHeader.getOrderItemList();
BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {
totalQuantity = totalQuantity.add(orderItem.getQuantity());
}
I know we want to encourage business logic in minlang, etc... but if it is
written in java, and there is a LOT of code in java, shopping cart, etc...
this makes that code MUST more readable and maintainable. The binding between
the entity model and the java implementation can be caught as a compile time
error... significantly lowers the maintenance cost of the code.
This may be pushing a rope, but we use this ALL the time for our groovy and java code.
(would also apply to jsp code obviously). Minilang code can be type checked by the
reader... (want to check for static errors in code, without the need to run
the code).
We have implemented the generators, and the refactoring/abstracting to enable this. We
find it works great and doesn't break ANY of the nice ofbiz extend entity semantics,
etc Of course if you extend an entity and then want java business logic to use it...
you need to access those items either with strings as stock ofbiz, or redo an
entity-gen. But if there is no java code using the entities, no need to auto-gen.
As another note, we have done a similar thing with the service interface as you might
have guessed, we're a fan of ofbiz extensibility, but NOT on how it encourages poor Java
implementation practices. (String object references, non-type safe, public
static methods everywhere etc...)
Marc
- Original Message -
On 10/12/2010, at 8:54 AM, Adam Heath wrote:
On 12/09/2010 01:48 PM, Scott Gray wrote:
On 10/12/2010, at 5:53 AM, Adam Heath wrote:
On 12/09/2010 12:03 AM, Scott Gray wrote:
On 9/12/2010, at 11:50 AM, Adam Heath wrote:
On 12/08/2010 03:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a
variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However,
I'm now starting to lean towards replacing with findList
instead. However, in my opinion, I think that will make
programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead
of an
EntityCondition. Without this new variant, there would be ton
of variants that would only need to import EntityCondition,
just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map,
doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little
more than
UtilMisc. In addition to the iteration over the array, it also
does a
check on the value for Comparable/Serializable. This latter
check seems a bit superfluous, as eventually the base
condition classes
check the values against the model.
So, from a purist stand point, even tho
Fwd: Re: demo server performance
Got kicked back so resend the search engines have the old link and if you change it will still use them plus the new ones. rewrites is the way to block urls. http://en.linuxreviews.org/HOWTO_stop_automated_spam-bots_using_.htaccess towards the bottom is some good examples. though this uses .htacess you should be able to put them in the virtural server or main part of the apache config. = 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/10/2010 2:27 AM: 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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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.
Fwd: Re: demo server performance
got kicked back resend. from the server side activity, one visit (one URL) is multiple Get requests. between 5 search engines I have continuous request on my ecommerce. the commerce side gets multiple Search engine requests at one time. most ecommerce sites consider 1,000 views per sec low and 100,000 per sec a successful site. so I doubt that ofbiz current requests are not much concern. = 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 Bruno Busco sent the following on 12/10/2010 1:24 AM: 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 Rouxjacques.le.r...@les7arts.com From: BJ Freemanbjf...@free-man.net 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.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970243#action_12970243 ] BJ Freeman commented on OFBIZ-4052: --- you disabled the url which I reversed on my demo :D Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
the facade is exactly what ofbiz wants to avoid.
the extra overhead of the conversion.
Marc Morin sent the following on 12/10/2010 8:17 AM:
This isn't Object-Relational mapping but Relational-Object mapping. It doesn't change
ANY of the obiz entity semantics, it just provides a facade over the entities that can
optionally be used by Java code (not framework code, but application layer) to recognize that
the business logic IS tightly bound to entity (by name), fields (by name) and relationships
between entities (by name). THis facade just moves these already existing bindings from
strings to Java native mechanisms, so that you get compile time errors, if you
rename an entity, field, type, relation, etc...
BUT most importantly, you don't get a bunch of GenericValue's and
ListGenericValue in the java application code. They become meaningful
business entities that allows code easier to follow and thus less bugs and easier to
maintain.
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmo...@emforium.com
- Original Message -
I have thought about this idea, and at first glance it seems cool and
all, but one of the selling points of OFBiz is that it intentionally
stays away from this type of Object-Relational mapping. OFBiz
developers find that direct access to the relational database is
easier to use.
-Adrian
On 12/10/2010 7:20 AM, Marc Morin wrote:
In the spirit of changing the entity/delegator interface more object
friendly, why not take this to then next step and generate POJO
interfaces for each entity. These would extend GenericValue but
provide a simple gettor/settor facade allowing compile time type
checking and removing of the string code for much of the business
logic written in java.
We have done such a thing (again in our forked application), and it
makes the Java code much more readable and easier to use. The
general structure is
public class Person extends AbstractGenericValuePerson
{
public static final String ENTITY = Person;
// constructor, only called from makeValue, MUST be associated
with a delegator
protected Person(Delegator delegator) {...}
// factory method
public static Person newInstance(Delegator delegator) {...}
// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String
partyId){...}
// getter and settors
public String getFirstName() {
return getString(firstName);
} public Person setFirstName(String value) {
set(firstName, value);
return this;
}
// relationships
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws
GenericEntityException{...}
}
This allows code that is much easier to debug and less error prone..
example below is for navigating orders.
OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);
// get the orderItems
ListOrderItem orderItems = orderHeader.getOrderItemList();
BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {
totalQuantity = totalQuantity.add(orderItem.getQuantity());
}
I know we want to encourage business logic in minlang, etc... but if
it is written in java, and there is a LOT of code in java, shopping
cart, etc... this makes that code MUST more readable and
maintainable. The binding between the entity model and the java
implementation can be caught as a compile time error...
significantly lowers the maintenance cost of the code.
This may be pushing a rope, but we use this ALL the time for our
groovy and java code. (would also apply to jsp code obviously).
Minilang code can be type checked by the reader... (want to check
for static errors in code, without the need to run the code).
We have implemented the generators, and the refactoring/abstracting
to enable this. We find it works great and doesn't break ANY of the
nice ofbiz extend entity semantics, etc Of course if you extend
an entity and then want java business logic to use it... you need to
access those items either with strings as stock ofbiz, or redo an
entity-gen. But if there is no java code using the entities, no need
to auto-gen.
As another note, we have done a similar thing with the service
interface as you might have guessed, we're a fan of ofbiz
extensibility, but NOT on how it encourages poor Java implementation
practices. (String object references, non-type safe, public static
methods everywhere etc...)
Marc
Re: Re: demo server performance
Yes, I used something like that in conf, I can't remember what exactly, your link seems OK Thanks Jacques From: BJ Freeman bjf...@free-man.net Got kicked back so resend the search engines have the old link and if you change it will still use them plus the new ones. rewrites is the way to block urls. http://en.linuxreviews.org/HOWTO_stop_automated_spam-bots_using_.htaccess towards the bottom is some good examples. though this uses .htacess you should be able to put them in the virtural server or main part of the apache config. = 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/10/2010 2:27 AM: 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 jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net 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: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
On 12/10/2010 11:54 AM, BJ Freeman wrote: the facade is exactly what ofbiz wants to avoid. the extra overhead of the conversion. I disagree. OOTB ofbiz should not use any such facades. But having them available for end-users to make use of is a win, IMHO. Makes it easier for new people to get involved in ofbiz. This facade pattern will obviously be slower; it contains more object instantiations, and more method calls. And, in groovy at least, those end up using reflection. But if it allows people to write more application code, which can later be optimized to be faster, then I'm all for it.
Re: demo server performance
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
Re: demo server performance
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.
Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
I am happy as long as not OOTB I doubt that there will be any effort to optimize, under current design, if they are done in OO way. as you said the path of least resistance with the fact that the volunteer group does not have energy to do that. 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/10/2010 10:17 AM: On 12/10/2010 11:54 AM, BJ Freeman wrote: the facade is exactly what ofbiz wants to avoid. the extra overhead of the conversion. I disagree. OOTB ofbiz should not use any such facades. But having them available for end-users to make use of is a win, IMHO. Makes it easier for new people to get involved in ofbiz. This facade pattern will obviously be slower; it contains more object instantiations, and more method calls. And, in groovy at least, those end up using reflection. But if it allows people to write more application code, which can later be optimized to be faster, then I'm all for it.
Re: jquey
Jacques, you have already ported in the jquery branch all the changes of the trunk. So now the jquery branch is actually how the trunk should be after the merge. Any conflict should be quickly resolved using the copy of the files from the jquery brqnch. -Bruno 2010/12/10 Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Yes, while mucking around with the trunk demo this morning I simply misused the merge (wrong way) and actually I have any conflicts to handle but a false one. It's committing... Jacques From: Bruno Busco bruno.bu...@gmail.com Jacques, you have already ported in the jquery branch all the changes of the trunk. So now the jquery branch is actually how the trunk should be after the merge. Any conflict should be quickly resolved using the copy of the files from the jquery brqnch. -Bruno 2010/12/10 Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970302#action_12970302 ] Jacques Le Roux commented on OFBIZ-4052: Of course I had also reverted my changes. So I really wonder why it works in your instance and not OOTB in the trunk and 2 of my instances, one being totally clean and OOTB (Derby) the other using Postgres... Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4051) i18n for elrte editor
[ https://issues.apache.org/jira/browse/OFBIZ-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970303#action_12970303 ] Jacques Le Roux commented on OFBIZ-4051: As I suspected this needs a bit more work to handle the language.country.couple case. I will handle it. I have found also a small bug. Anyway I'm merging the branchin the trunk so it will be fixed in the trunk... i18n for elrte editor - Key: OFBIZ-4051 URL: https://issues.apache.org/jira/browse/OFBIZ-4051 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Affects Versions: jQuery Reporter: Erwan de FERRIERES Assignee: Erwan de FERRIERES Priority: Minor Fix For: jQuery Attachments: elrte_i18n.patch, elrte_i18n.zip elrte editor has its i18n files included in the archive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4051) i18n for elrte editor
[ https://issues.apache.org/jira/browse/OFBIZ-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970306#action_12970306 ] Jacques Le Roux commented on OFBIZ-4051: Oops sorry, it's ok, actually it was only the language file which was missing. So only this little bug to fix when you come from a form, cool :) i18n for elrte editor - Key: OFBIZ-4051 URL: https://issues.apache.org/jira/browse/OFBIZ-4051 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Affects Versions: jQuery Reporter: Erwan de FERRIERES Assignee: Erwan de FERRIERES Priority: Minor Fix For: jQuery Attachments: elrte_i18n.patch, elrte_i18n.zip elrte editor has its i18n files included in the archive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: findByAnd(Map) ws findList(EntityCondition)
On 11/12/2010, at 4:20 AM, Marc Morin wrote: In the spirit of changing the entity/delegator interface more object friendly, why not take this to then next step and generate POJO interfaces for each entity. These would extend GenericValue but provide a simple gettor/settor facade allowing compile time type checking and removing of the string code for much of the business logic written in java. [snip] This allows code that is much easier to debug and less error prone.. example below is for navigating orders. [snip] The binding between the entity model and the java implementation can be caught as a compile time error... significantly lowers the maintenance cost of the code. In my experience this is simply untrue and something that seems like it might be the case but actually isn't. The number of bug fixes going into the trunk for incorrectly named entities/fields is minuscule and I would be surprised if it were any more than a couple per year, hardly a source of significant maintenance costs. Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: demo server performance
From: Jacques Le Roux jacques.le.r...@les7arts.com From: Adam Heath doo...@brainfood.com 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 I have tried to use both (on 3 new trunk threads running amok) kill -QUIT PID kill -3 PID but got no stack traces, nothing at all :/ Jacques PS: I have also tried on the main PID
[jira] Commented: (OFBIZ-3485) Error in updating party postal address if party has an EftAccount
[ https://issues.apache.org/jira/browse/OFBIZ-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970344#action_12970344 ] Si Chen commented on OFBIZ-3485: What happened to this? Has it been fixed? Error in updating party postal address if party has an EftAccount -- Key: OFBIZ-3485 URL: https://issues.apache.org/jira/browse/OFBIZ-3485 Project: OFBiz Issue Type: Bug Reporter: Abdullah Shaikh Try to update the party Postal Address, which have an EftAccount, using the Update button in Profile's Contact Information section, you get the below error, The Following Errors Occurred: Error trying to begin transaction, could not process method: The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Service [updateEftAccount] threw an unexpected exception/errororg.ofbiz.service.ServiceValidationException: The following required parameter is missing: [updateEftAccount.nameOnAccount] (The following required parameter is missing: [updateEftAccount.nameOnAccount]) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970350#action_12970350 ] BJ Freeman commented on OFBIZ-4052: --- so if I understand this, you applied the patch and it did not work. since I make changes on the server then copy them into my copy of the svn, I may have missed a change, will check out. Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
The facade doesn't instantiate more objects than current, but the class hierarchy is taller. (ie. when GenericValue.makeValue() currently instantiates a GenericValue(), that factory would then instantiate a class based on the entity name, that derives from GenericValue()). The speed of the extra layer for the getter/setter is not worth mentioning. I disagree that OOTB OFBiz should not use this in any part of the offering. The Entity engine should not be dependent on any Entity instance as it isn't, but OFBiz's applications benefits tremendously! Even framework code such as the ControlServlet that is accessing the Visit entity, it has a code dependency between the Visit entity and the Java code, using a Visit facade over GenericValue with visitId,etc... doesn't hurt. The code for orders, product, etc.. become much easier to understand, follow and maintain. I don't see any downside on any OFBiz code implemented in Java not using this pattern. Am I pushing a rope on this issue? If so, I will stop debating... Marc - Original Message - I am happy as long as not OOTB I doubt that there will be any effort to optimize, under current design, if they are done in OO way. as you said the path of least resistance with the fact that the volunteer group does not have energy to do that. 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/10/2010 10:17 AM: On 12/10/2010 11:54 AM, BJ Freeman wrote: the facade is exactly what ofbiz wants to avoid. the extra overhead of the conversion. I disagree. OOTB ofbiz should not use any such facades. But having them available for end-users to make use of is a win, IMHO. Makes it easier for new people to get involved in ofbiz. This facade pattern will obviously be slower; it contains more object instantiations, and more method calls. And, in groovy at least, those end up using reflection. But if it allows people to write more application code, which can later be optimized to be faster, then I'm all for it.
[jira] Updated: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BJ Freeman updated OFBIZ-4052: -- Attachment: OFBIZ-4052Docbookfiles.patch had an extra file that was not needed. uploaded modified patch Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
On 12/10/2010 06:37 PM, Marc Morin wrote: The facade doesn't instantiate more objects than current, but the class hierarchy is taller. (ie. when GenericValue.makeValue() currently instantiates a GenericValue(), that factory would then instantiate a class based on the entity name, that derives from GenericValue()). A class based on GenericValue(even one generated dynamically at runtime, into a custom classloader), is still a class. Said class is not loaded on the heap. It's bytecode is placed into permgen. More classes would increase permgen pressure.
Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))
Yes, permgen space needs to be increased with this. Sorry, I mis-understood your objection as a performance related to speed of the newInstance() vs more classes. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com - Original Message - On 12/10/2010 06:37 PM, Marc Morin wrote: The facade doesn't instantiate more objects than current, but the class hierarchy is taller. (ie. when GenericValue.makeValue() currently instantiates a GenericValue(), that factory would then instantiate a class based on the entity name, that derives from GenericValue()). A class based on GenericValue(even one generated dynamically at runtime, into a custom classloader), is still a class. Said class is not loaded on the heap. It's bytecode is placed into permgen. More classes would increase permgen pressure.
[jira] Updated: (OFBIZ-4051) i18n for elrte editor
[
https://issues.apache.org/jira/browse/OFBIZ-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dukian updated OFBIZ-4051:
--
Attachment: elret-zh_TW-modified-result.jpg
OFBIZ-4051_zh_TW.patch
Thanks for Jacques highlights Chinese issue.
After checks two cases: datepicker is fine, but el-rte not.
There are many different i18n file naming approaches for Traditional Chinese
... OFBiz uses java way: zh_TW, datepicker uses zh-TW, and el-rte needs patch
as attachment(OFBIZ-4051_zh_TW.patch).
According to elrte.(min|full).js, the full version is Line 1108:
{quote}
this.lang = (''+this.options.lang).toLowerCase();
this._i18n = new eli18n({textdomain : 'rte', messages : { rte :
this.i18Messages[this.lang] || {}} });
{quote}
el-rte needs lower case TWO_LETTER_LANG_CODE in translation file.
I'll file this issue to el-rte project too.
i18n for elrte editor
-
Key: OFBIZ-4051
URL: https://issues.apache.org/jira/browse/OFBIZ-4051
Project: OFBiz
Issue Type: Sub-task
Components: ALL COMPONENTS
Affects Versions: jQuery
Reporter: Erwan de FERRIERES
Assignee: Erwan de FERRIERES
Priority: Minor
Fix For: jQuery
Attachments: elret-zh_TW-modified-result.jpg, elrte_i18n.patch,
elrte_i18n.zip, OFBIZ-4051_zh_TW.patch
elrte editor has its i18n files included in the archive
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
