You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Alexis Midon (JIRA)" <ji...@apache.org> on 2009/10/03 06:18:23 UTC
[jira] Created: (ODE-671) clean up queries in HLargeData are too
broad
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] Resolved: (ODE-671) clean up queries in HLargeData are too
broad
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin resolved ODE-671.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.0-beta3
1.3.4
> 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
> Fix For: 1.3.4, 2.0-beta3
>
>
> (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
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ 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@f4af3a.getUTCTime(...)}
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@f4af3a.getUTCTime(...)}
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
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ 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@f4af3a.getUTCTime(...)}
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] Assigned: (ODE-671) clean up queries in HLargeData are too
broad
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ 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
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.