Difference between revisions of "IDempiere/FullMeeting20150128"

From WikiQSS
(full meeting)
 
(drop JIRA notifications from log)
 
Line 14: Line 14:
 
'''''aguerra''''': Buenos dias<br>
 
'''''aguerra''''': Buenos dias<br>
 
'''''CarlosRuiz''''': Hi Alejandro<br>
 
'''''CarlosRuiz''''': Hi Alejandro<br>
'''''Not-ae23''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/<br>
 
'''''Not-ae23''''': [iDempiere] globalqss 1e89e66 - IDEMPIERE-386 IDEMPIERE-1770 minor - drop unused code and improve order by<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2421 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Cannot Reproduce"<br>
 
'''''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<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2244<br>
 
'''''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.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244<br>
 
'''''Not-ae23''''': [IDEMPIERE] nmicoud updated IDEMPIERE-2244<br>
 
'''''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<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244<br>
 
'''''Not-ae23''''': [IDEMPIERE] hieplq updated IDEMPIERE-2244<br>
 
'''''Not-ae23''''': [IDEMPIERE] [~carlosruiz_globalqss] RequestEMailProcessorNew will replace RequestEMailProcessor in AD_Process. must manual change it.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2244 Attachment set to "IDEMPIERE-2244_req.patch"<br>
 
'''''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.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2244<br>
 
 
'''''aguerra''''': hi Carlos<br>
 
'''''aguerra''''': hi Carlos<br>
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2112<br>
 
'''''Not-ae23''''': [IDEMPIERE] agree [~hieplq], better if esc close just one window<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2112<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2419<br>
 
'''''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.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2420<br>
 
'''''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.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2420<br>
 
'''''Not-ae23''''': [IDEMPIERE] hieplq updated IDEMPIERE-2419<br>
 
'''''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).<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2419<br>
 
'''''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<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2419<br>
 
'''''Not-ae23''''': [IDEMPIERE] fabiocanella updated IDEMPIERE-2421<br>
 
'''''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<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421<br>
 
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2421<br>
 
'''''Not-ae23''''': [IDEMPIERE] according to the code, there must be two records maybe with same locator, product, asi and date<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421<br>
 
 
'''''CarlosRuiz''''': Hi fabiocanella <br>
 
'''''CarlosRuiz''''': Hi fabiocanella <br>
 
'''''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<br>
 
'''''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<br>
Line 72: Line 34:
 
'''''CarlosRuiz''''': in idempiere we changed that to create one storage record for each date when there is no ASI<br>
 
'''''CarlosRuiz''''': in idempiere we changed that to create one storage record for each date when there is no ASI<br>
 
'''''fabiocanella''''': yes I read this in the link you send me, ok now I understand better I try to debug, thanks<br>
 
'''''fabiocanella''''': yes I read this in the link you send me, ok now I understand better I try to debug, thanks<br>
'''''Not-ae23''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2224 Attachment set to "IDEMPIERE-2224_CR.patch"<br>
 
'''''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.<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2224<br>
 
 
'''''CarlosRuiz''''': yw<br>
 
'''''CarlosRuiz''''': yw<br>
 
'''''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 :)<br>
 
'''''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 :)<br>
Line 100: Line 59:
 
'''''nmicoud''''': interesting !<br>
 
'''''nmicoud''''': interesting !<br>
 
'''''nmicoud''''': will update the ticket with this discussion and try to do it<br>
 
'''''nmicoud''''': will update the ticket with this discussion and try to do it<br>
'''''Not-ae23''''': [IDEMPIERE] nmicoud updated IDEMPIERE-2224<br>
 
'''''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 <br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2224<br>
 
 
'''''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<br>
 
'''''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<br>
 
'''''CarlosRuiz''''': yep - in the postgres seed there is no _key - just the _pkey<br>
 
'''''CarlosRuiz''''': yep - in the postgres seed there is no _key - just the _pkey<br>
 
'''''CarlosRuiz''''': migrated?<br>
 
'''''CarlosRuiz''''': migrated?<br>
 
'''''fabiocanella''''': problably... I don't know<br>
 
'''''fabiocanella''''': problably... I don't know<br>
'''''Not-ae23''''': [IDEMPIERE] fabiocanella updated IDEMPIERE-2421<br>
 
'''''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<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2421<br>
 
 
'''''norbertbede''''': HI CarlosRuiz<br>
 
'''''norbertbede''''': HI CarlosRuiz<br>
 
'''''norbertbede''''': i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420<br>
 
'''''norbertbede''''': i found some workaround to https://idempiere.atlassian.net/browse/IDEMPIERE-2420<br>
Line 116: Line 69:
 
'''''norbertbede''''': after close tab and login again system works well<br>
 
'''''norbertbede''''': after close tab and login again system works well<br>
 
'''''norbertbede''''': hope help<br>
 
'''''norbertbede''''': hope help<br>
'''''Not-ae23''''': [IDEMPIERE] norbert.bede updated IDEMPIERE-2420<br>
 
'''''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]<br>
 
'''''Not-ae23''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2420<br>
 
 
'''''CarlosRuiz''''': ah yes - that was the case where it thrown that error to me - using the support button - didn't remember<br>
 
'''''CarlosRuiz''''': ah yes - that was the case where it thrown that error to me - using the support button - didn't remember<br>
 
'''''Edwin_Ang''''': hi<br>
 
'''''Edwin_Ang''''': hi<br>

Latest revision as of 08:58, 29 January 2015

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
aguerra: hi Carlos
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
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
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
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
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