IDempiere/FullMeeting20150128 - Revision history

CarlosRuiz: drop JIRA notifications from log

2015-01-29T13:58:00Z

drop JIRA notifications from log

CarlosRuiz: full meeting

2015-01-29T13:57:41Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|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

@@ Line 14: / Line 14: @@
 '''''aguerra''''': Buenos dias<br>
 '''''CarlosRuiz''''': Hi Alejandro<br>
 '''''aguerra''''': hi Carlos<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>
@@ Line 72: / Line 34: @@
 '''''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>
 '''''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>
@@ Line 100: / Line 59: @@
 '''''nmicoud''''': interesting !<br>
 '''''nmicoud''''': will update the ticket with this discussion and try to do it<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''''': migrated?<br>
 '''''fabiocanella''''': problably... I don't know<br>
 '''''norbertbede''''': HI CarlosRuiz<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''''': hope help<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>