|

»

[jira] Created: (ODE-671) clean up queries in HLargeData are too broad

View: New views

5 Messages — Rating Filter: Alert me

	[jira] Created: (ODE-671) clean up queries in HLargeData are too broad by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message clean up queries in HLargeData are too broad -------------------------------------------- Key: ODE-671 URL: https://issues.apache.org/jira/browse/ODE-671 Project: ODE Issue Type: Bug Reporter: Alexis Midon (Regression presumably introduced by ODE-641) The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing. For instance: deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list()); a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) This returns a list of null values b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever. The fix is to add a 'is not null' clause in a. I used the following Derby properties to gather information. -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Assigned: (ODE-671) clean up queries in HLargeData are too broad by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafal Rusin reassigned ODE-671: ------------------------------- Assignee: Rafal Rusin > clean up queries in HLargeData are too broad > -------------------------------------------- > > Key: ODE-671 > URL: https://issues.apache.org/jira/browse/ODE-671 > Project: ODE > Issue Type: Bug > Reporter: Alexis Midon > Assignee: Rafal Rusin > > (Regression presumably introduced by ODE-641) > The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing. > For instance: > deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list()); > a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) > This returns a list of null values > b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever. > The fix is to add a 'is not null' clause in a. > I used the following Derby properties to gather information. > -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (ODE-671) clean up queries in HLargeData are too broad by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763275#action_12763275 ] Rafal Rusin commented on ODE-671: --------------------------------- I merged it, but I wasn't able to run axis-war tests successfully (especially TestCleanSucces etc.), because of http error for TimeService. Can you check it out? BTW. I think we need to move external http requests to local in tests. DEBUG - GeronimoLog.debug(66) \| <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><addr:To xmlns:addr="http://www.w3.org/2005/0 8/addressing">http://ws.intalio.com/TimeService/</addr:To><addr:Action xmlns:addr="http://www.w3.org/2005/08/addressing">http://ws.intalio.com/TimeService/getUTCTime</addr:Action><addr:ReplyTo xmlns:addr="ht tp://www.w3.org/2005/08/addressing"><addr:Address>http://www.w3.org/2005/08/addressing/anonymous</addr:Address></addr:ReplyTo><addr:MessageID xmlns:addr="http://www.w3.org/2005/08/addressing">uuid:hqejbhcnph r4niqp1hpeia</addr:MessageID></soapenv:Header><soapenv:Body><getUTCTime xmlns="http://ws.intalio.com/TimeService/" /></soapenv:Body></soapenv:Envelope> ERROR - GeronimoLog.error(108) \| Error sending message to Axis2 for ODE mex {PartnerRoleMex#hqejbhcnphr4niqp1hpei7 [PID null] calling org.apache.ode.il.epr.WSAEndpoint@...(...)} org.apache.axis2.AxisFault: Transport error: 503 Error: Service Temporarily Unavailable at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:296) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:371) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:209) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.ode.axis2.soapbinding.SoapExternalService.invoke(SoapExternalService.java:174) at org.apache.ode.axis2.MessageExchangeContextImpl.invokePartnerUnreliable(MessageExchangeContextImpl.java:61) at org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl$UnreliableInvoker.run(PartnerLinkPartnerRoleImpl.java:334) at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:741) at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:977) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) > clean up queries in HLargeData are too broad > -------------------------------------------- > > Key: ODE-671 > URL: https://issues.apache.org/jira/browse/ODE-671 > Project: ODE > Issue Type: Bug > Reporter: Alexis Midon > Assignee: Rafal Rusin > > (Regression presumably introduced by ODE-641) > The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing. > For instance: > deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list()); > a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) > This returns a list of null values > b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever. > The fix is to add a 'is not null' clause in a. > I used the following Derby properties to gather information. > -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Issue Comment Edited: (ODE-671) clean up queries in HLargeData are too broad by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763275#action_12763275 ] Rafal Rusin edited comment on ODE-671 at 10/7/09 2:28 PM: ---------------------------------------------------------- I merged it, but I wasn't able to run axis-war tests successfully (especially TestCleanSucces etc.), because of http error for TimeService. Can you check out if those tests pass? BTW. I think we need to move external http requests to local in tests. DEBUG - GeronimoLog.debug(66) \| <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><addr:To xmlns:addr="http://www.w3.org/2005/0 8/addressing">http://ws.intalio.com/TimeService/</addr:To><addr:Action xmlns:addr="http://www.w3.org/2005/08/addressing">http://ws.intalio.com/TimeService/getUTCTime</addr:Action><addr:ReplyTo xmlns:addr="ht tp://www.w3.org/2005/08/addressing"><addr:Address>http://www.w3.org/2005/08/addressing/anonymous</addr:Address></addr:ReplyTo><addr:MessageID xmlns:addr="http://www.w3.org/2005/08/addressing">uuid:hqejbhcnph r4niqp1hpeia</addr:MessageID></soapenv:Header><soapenv:Body><getUTCTime xmlns="http://ws.intalio.com/TimeService/" /></soapenv:Body></soapenv:Envelope> ERROR - GeronimoLog.error(108) \| Error sending message to Axis2 for ODE mex {PartnerRoleMex#hqejbhcnphr4niqp1hpei7 [PID null] calling org.apache.ode.il.epr.WSAEndpoint@...(...)} org.apache.axis2.AxisFault: Transport error: 503 Error: Service Temporarily Unavailable at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:296) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:371) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:209) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.ode.axis2.soapbinding.SoapExternalService.invoke(SoapExternalService.java:174) at org.apache.ode.axis2.MessageExchangeContextImpl.invokePartnerUnreliable(MessageExchangeContextImpl.java:61) at org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl$UnreliableInvoker.run(PartnerLinkPartnerRoleImpl.java:334) at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:741) at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:977) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) was (Author: rrusin): I merged it, but I wasn't able to run axis-war tests successfully (especially TestCleanSucces etc.), because of http error for TimeService. Can you check it out? BTW. I think we need to move external http requests to local in tests. DEBUG - GeronimoLog.debug(66) \| <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><addr:To xmlns:addr="http://www.w3.org/2005/0 8/addressing">http://ws.intalio.com/TimeService/</addr:To><addr:Action xmlns:addr="http://www.w3.org/2005/08/addressing">http://ws.intalio.com/TimeService/getUTCTime</addr:Action><addr:ReplyTo xmlns:addr="ht tp://www.w3.org/2005/08/addressing"><addr:Address>http://www.w3.org/2005/08/addressing/anonymous</addr:Address></addr:ReplyTo><addr:MessageID xmlns:addr="http://www.w3.org/2005/08/addressing">uuid:hqejbhcnph r4niqp1hpeia</addr:MessageID></soapenv:Header><soapenv:Body><getUTCTime xmlns="http://ws.intalio.com/TimeService/" /></soapenv:Body></soapenv:Envelope> ERROR - GeronimoLog.error(108) \| Error sending message to Axis2 for ODE mex {PartnerRoleMex#hqejbhcnphr4niqp1hpei7 [PID null] calling org.apache.ode.il.epr.WSAEndpoint@...(...)} org.apache.axis2.AxisFault: Transport error: 503 Error: Service Temporarily Unavailable at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:296) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:371) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:209) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.ode.axis2.soapbinding.SoapExternalService.invoke(SoapExternalService.java:174) at org.apache.ode.axis2.MessageExchangeContextImpl.invokePartnerUnreliable(MessageExchangeContextImpl.java:61) at org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl$UnreliableInvoker.run(PartnerLinkPartnerRoleImpl.java:334) at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:741) at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:977) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) > clean up queries in HLargeData are too broad > -------------------------------------------- > > Key: ODE-671 > URL: https://issues.apache.org/jira/browse/ODE-671 > Project: ODE > Issue Type: Bug > Reporter: Alexis Midon > Assignee: Rafal Rusin > > (Regression presumably introduced by ODE-641) > The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing. > For instance: > deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list()); > a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) > This returns a list of null values > b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever. > The fix is to add a 'is not null' clause in a. > I used the following Derby properties to gather information. > -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (ODE-671) clean up queries in HLargeData are too broad by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763706#action_12763706 ] Knut Anders Hatlen commented on ODE-671: ---------------------------------------- This is probably caused by DERBY-4376, which was fixed recently. Unfortunately, the fix is not available in any official release yet. > clean up queries in HLargeData are too broad > -------------------------------------------- > > Key: ODE-671 > URL: https://issues.apache.org/jira/browse/ODE-671 > Project: ODE > Issue Type: Bug > Reporter: Alexis Midon > Assignee: Rafal Rusin > > (Regression presumably introduced by ODE-641) > The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing. > For instance: > deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list()); > a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) > This returns a list of null values > b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever. > The fix is to add a 'is not null' clause in a. > I used the following Derby properties to gather information. > -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.