IDempiere/FullMeeting20150128

From WikiQSS
Revision as of 09:57, 29 January 2015 by CarlosRuiz (talk | contribs) (full meeting)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2015-01-28

CarlosRuiz: Good morning
nmicoud: Hi Carlos
nmicoud: Any chance you can review those following tickets : 2224, 2411, 2235 ?
CarlosRuiz: ok, I'll try to review them today
nmicoud: thanks
aguerra: Buenos dias
CarlosRuiz: Hi Alejandro
Not-ae23: [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/
Not-ae23: [iDempiere] globalqss 1e89e66 - IDEMPIERE-386 IDEMPIERE-1770 minor - drop unused code and improve order by
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2421 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Cannot Reproduce"
Not-ae23: [IDEMPIERE] [~fabiocanella], I was not able to reproduce the issue. Looking at the code maybe you have duplicates in your M_StorageOnHand table. If you find a case able to be reproduced please reopen the ticket with steps to reproduce. Regards, Carlos Ruiz
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2244
Not-ae23: [IDEMPIERE] [~nmicoud] have you tested this patch? [~hieplq], the patch refers to a new class RequestEMailProcessorNew which is not referenced in the AD_Process record.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244
Not-ae23: [IDEMPIERE] nmicoud updated IDEMPIERE-2244
Not-ae23: [IDEMPIERE] Yes, i've tested it. AFAIR, Hiep write a new java class for testing purpose. The 'old' one should be deleted and RequestEMailProcessorNew renamed as RequestEMailProcessor Nicolas
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244
Not-ae23: [IDEMPIERE] hieplq updated IDEMPIERE-2244
Not-ae23: [IDEMPIERE] [~carlosruiz_globalqss] RequestEMailProcessorNew will replace RequestEMailProcessor in AD_Process. must manual change it.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2244 Attachment set to "IDEMPIERE-2244_req.patch"
Not-ae23: [IDEMPIERE] I'm attaching the patch migrated to RequestEMailProcessor, can you please test IDEMPIERE-2244_req.patch I see there is a new parameter to the process with name "p_nestInbox" - but no migration script to create it. Also I see an old hardcoded value (since original version) for "postmaster@CONSULTDESK" - I don't remember the purpose of such verification, but seems unnecessary at this moment, we could drop it.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244
aguerra: hi Carlos
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2112
Not-ae23: [IDEMPIERE] agree [~hieplq], better if esc close just one window
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2112
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2419
Not-ae23: [IDEMPIERE] Hi [~hieplq], I think this issue is just for r3? If yes, I think is a blocker as indeed there are big reports in any installation, and we need to try to create a reproducible test case and fix it asap for r3 stabilization.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2420
Not-ae23: [IDEMPIERE] I've been hit by this same jetty exception - but was not reproducible when I retried. Great if we could find a reproducible test case.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2420
Not-ae23: [IDEMPIERE] hieplq updated IDEMPIERE-2419
Not-ae23: [IDEMPIERE] now, i will test it in 2.1 and report late. i can provide my data to test it (at private channel).
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2419
Not-ae23: [IDEMPIERE] sometimes I use to create a view for testing purposes, for example this query returns 39.627.025 rows: select e1.* from ad_element e1, ad_element e2
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419
Not-ae23: [IDEMPIERE] fabiocanella updated IDEMPIERE-2421
Not-ae23: [IDEMPIERE] Thanks Carlos, as you said there are many "duplicates" rows in M_StorageOnHand table: same M_LOCATOR_ID, M_PRODUCT_ID and M_ATTRIBUTESETINSTANCE_ID value but different DATEMATERIALPOLICY value is not correct ? what you mean by duplicates rows ? Best Regards, Fabio
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2421
Not-ae23: [IDEMPIERE] according to the code, there must be two records maybe with same locator, product, asi and date
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421
CarlosRuiz: Hi fabiocanella
fabiocanella: Hi Carlos regarding the issue in table IDEMPIERE-2421 I don't know how M_StorageOnHand work: I see that there is M_STORAGEONHAND_PKEY so can't be 2 rows with the same locator, product, asi and date, right
fabiocanella: ?
CarlosRuiz: yep
CarlosRuiz: what I reviewed is: the MInventory.java in line 658
CarlosRuiz: calls
CarlosRuiz: MStorageOnHand[] storages = MStorageOnHand.getWarehouse ...
CarlosRuiz: that gets the records on the locator/product - so you can have several asi and date
CarlosRuiz: and then for each storage it inserts one MInventoryLineMA
fabiocanella: ok
CarlosRuiz: using the asi and date
CarlosRuiz: so, what I understand is that in principle is not possible to insert duplicates - but maybe I'm reading wrong
CarlosRuiz: hard to debug without a broken test case
fabiocanella: ok, I understand... the DateMaterialPolicy if use only for FIFO/LIFO ?
CarlosRuiz: yes
CarlosRuiz: old adempiere used to create one storage record for each ASI
CarlosRuiz: even when there was no really ASI
CarlosRuiz: in idempiere we changed that to create one storage record for each date when there is no ASI
fabiocanella: yes I read this in the link you send me, ok now I understand better I try to debug, thanks
Not-ae23: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2224 Attachment set to "IDEMPIERE-2224_CR.patch"
Not-ae23: [IDEMPIERE] [~nmicoud], I found a simpler patch with the same results, attached as IDEMPIERE-2224_CR.patch But, my concern about this (same on your patch) is that it's too expensive, it's creating a PO object on any DataStatusEvent, and there are many. If you set a breakpoint on GridTable.getPO you'll see how many PO objects are created on each event. IMHO this cost is prohibitive and we would need to find a lighter approach.
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2224
CarlosRuiz: yw
nmicoud: CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it :)
CarlosRuiz: maybe you can try to implement formatting on Env.parseContext
nmicoud: already try that. and need PO
CarlosRuiz: I tried and got stuck because Env.parseContext manages Strings - maybe you could discover the datatype of the column and use number / date or messageformat according to the datatype
nmicoud: hum...
nmicoud: will try this
CarlosRuiz: another possibility could be
CarlosRuiz: over the patch we're working - restrict the DataStatusEvents where the getPO is called
CarlosRuiz: at this moment is called every time - but maybe we can call it just when opening the window - navigating and saving - one time per each - I see sometimes the DataStatusEvent is passed twice on some cases
nmicoud: and what about adding a new event "refresh window title", which could be called only when a title logic is defined and after previous, next, save ?
CarlosRuiz: also noticed that Env.parseVariable manages format, but not default - and parseContext manages default but not format - it would be good to unify both approaches
CarlosRuiz: it could be possible to manage in both cases @variable<format>:default@
nmicoud: yes, seems necessary
CarlosRuiz: but would need to solve the datatype resolution on Env.parseContext - not easy as you just have the WindowNo
nmicoud: and a new syntax @variable<format><datatype>:default@ ?
CarlosRuiz: ah - that sounds interesting
nmicoud: ugly, but it should work :)
CarlosRuiz: easier and it will avoid the cost of resolving the datatype from dictionary
nmicoud: yep
CarlosRuiz: I think it can be good to implement a variable resolver - that parses such thing (variable/format/datatype/default) and we call it from both parseContext and parseVariable
CarlosRuiz: that will solve your issue too, right - no need for the PO for the title logic if we implement such thing
nmicoud: yes
nmicoud: interesting !
nmicoud: will update the ticket with this discussion and try to do it
Not-ae23: [IDEMPIERE] nmicoud updated IDEMPIERE-2224
Not-ae23: [IDEMPIERE] IRC [18:37] <nmicoud> CarlosRuiz : do you have any idea for a lighter approach ? i though about something like a list of values (reading the title logic) which will be stored, and if one of these value is updated, then we could create PO and get the new value. But 1st, not sure is a good idea. And 2nd, no idea for doing it :) [18:38] <@CarlosRuiz> maybe you can try to implement formatting on Env.parseContext [18:39] <nmicoud> already try
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2224
fabiocanella: I think i found the problem: in the database there is a M_INVENTORY_KEY index and also M_INVENTORY_PKEY, problably the KEY (without P) is the old unique key
CarlosRuiz: yep - in the postgres seed there is no _key - just the _pkey
CarlosRuiz: migrated?
fabiocanella: problably... I don't know
Not-ae23: [IDEMPIERE] fabiocanella updated IDEMPIERE-2421
Not-ae23: [IDEMPIERE] I found the solution: there was an old key M_INOUTLINEMA_KEY that is wrong, the new key is M_INOUTLINEMA_PKEY I deleted the old one and now it seem ok this was probably a migration error
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421
norbertbede: HI CarlosRuiz
norbertbede: i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420
CarlosRuiz: Hi norbertbede
norbertbede: when i click to Feedback>>Email to Support mentioned error log appear and session hangup
norbertbede: after close tab and login again system works well
norbertbede: hope help
Not-ae23: [IDEMPIERE] norbert.bede updated IDEMPIERE-2420
Not-ae23: [IDEMPIERE] when i click to Feedback>>Email to Support mentioned error log appear and session hangup. After close tab and login again system works well. 22:32:18.359-----------> HttpParser.parseNext: badMessage: java.lang.IllegalStateException: too much data after closed for HttpChannelOverHttp@76863770{r=1,c=false,a=IDLE,uri=-} [31]
Not-ae23: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2420
CarlosRuiz: ah yes - that was the case where it thrown that error to me - using the support button - didn't remember
Edwin_Ang: hi
Edwin_Ang: anyone here?
CarlosRuiz: Hi Edwin_Ang
Edwin_Ang: Hi Carlos
Edwin_Ang: can I ask a simple question?
Edwin_Ang: i tried the development branch and I can't seem to change the logging level for jetty
CarlosRuiz: you just did :-)
Edwin_Ang: :D
Edwin_Ang: the DEBUG msg are really annoying
CarlosRuiz: ah - I think hiep raised that in forums - but don't remember if he get any answer
Edwin_Ang: i tried various method suggested in the jetty docs
Edwin_Ang: but none working atm

Retrieved from "http://www.globalqss.com/wiki/index.php?title=IDempiere/FullMeeting20150128&oldid=491"