Re: Throttler mock endpoint question
Hi
You could just let it route to the mock endpoint.
And then afterwards check at what time they arrived at the mock
endpoint, to see if there is at most 7 within a second.
And btw I think we should add a header to the mock endpoint which
records the arrival time. For now you have to do that yourself.
For example using targetMock.whenAnyExchange(new Processor() {
// set time for arrival
}
On Sat, Apr 10, 2010 at 8:35 PM, Pavel pag...@gmail.com wrote:
Hi,
I'm fine with +/- 10%, but perhaps with my massive examples I shifted the
focus away from the original issue:
Route throttler is configured for 7 messages per second, but mock endpoint
will match message count of 7, or 14, or anything in between.
Thus the closest test I can do to verify intended limit of 7/second is
targetMock.expectedMinimumMessageCount(15);
targetMock.setResultWaitTime(1000);
...
targetMock.assertIsNotSatisfied();
... which is +/- 114%, and value of such test is questionable.
And I'm trying to figure out which of the following is the case
1. My code or test is incorrect
2. There is an issue with throttler
3. There is an issue with mock endpoint
4. Mock endpoint by design is not the right tool for the job
If #3 or #4, I'll need different approach to testing. Otherwise
implementation needs to be changed.
Thanks,
Pavel
On Sat, Apr 10, 2010 at 7:04 PM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
You can newer trust 100% on System time millis as its not accurate. So
make assertions on a given +/- delta.
On Sat, Apr 10, 2010 at 5:27 PM, Pavel pag...@gmail.com wrote:
Tried that, and noticed a few differences. maximumRequestsPerPeriod is 7.
* Expected message count 7 consistently fails with Expected X, but
was
7
* Expected message count 7-11 passes
* Expected message count 12,13 seems racy: sometimes test would fail with
Expected X, but was X+1
* Expected message count 14,15 passes (or I simply did not catch races).
* Expected message count 16-18 is racy again, e.g. Expected 17, but
was
19
* Expected message count 30 is racy, e.g. Expected: 30 but was: 32
That is not 100% precise, as I was giving limited number of tries for
each
case.
BTW, camel 2.2.0, activemq-camel 5.3.1.
Thanks,
Pavel
On Sat, Apr 10, 2010 at 2:31 PM, Claus Ibsen claus.ib...@gmail.com
wrote:
Hi
Can you try with
targetMock.assertIsSatisfied(1000);
On Sat, Apr 10, 2010 at 11:43 AM, Pavel pag...@gmail.com wrote:
Hello,
I'm facing strange behaviour of throttler + mock endpoint when route
under
test is this:
camel:route
camel:from uri=activemq:A/
camel:transacted/
camel:throttle timePeriodMillis=1000
maximumRequestsPerPeriod=7
camel:to uri=activemq:B /
/camel:throttle
/camel:route
test itself defines producer for direct - activemq:A route, as well
as
activemq:B - targetMock route, and then does this:
targetMock.expectedMessageCount(7);
targetMock.setResultWaitTime(1000);
for(int i=0; i40; i++)
{
producer.sendBody(Message + i);
}
targetMock.assertIsSatisfied();
This passes.
*BUT* if I change targetMock.expectedMessageCount(7); to e.g.
targetMock.expectedMessageCount(11); it passes as well!
Looks like test would pass if expectedMessageCount is anything between
[maximumRequestsPerPeriod, 2* maximumRequestsPerPeriod].
I tested various expected message counts against
maximumRequestsPerPeriod=7
3: Expected: 3 but was: 7
4: Expected: 4 but was: 7
5: Expected: 5 but was: 7
6: Expected: 6 but was: 7
7: passed
8: passed
9: passed
10: passed
11: passed
12: passed
13: passed
14: passed
15: Expected: 15 but was: 14
16: Expected: 16 but was: 14
17: Expected: 17 but was: 14
18: Expected: 18 but was: 14
19: Expected: 19 but was: 14
20: Expected: 20 but was: 14
... and against maximumRequestsPerPeriod=3
2: Expected: 2 but was: 3
3: passed
4: passed
5: passed
6: passed
7: Expected: 7 but was: 6
8: Expected: 8 but was: 6
9: Expected: 9 but was: 6
10: Expected: 10 but was: 6
Can you please explain that? Is it some sort of mock endpoint
specifics?
I'd like my test to be fairly strict, as the goal is to verify that
route
meets SLA...
Thanks,
Pavel
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel
Re: Throttler mock endpoint question
Hi
I have created ticket
https://issues.apache.org/activemq/browse/CAMEL-2630
You can comment any ideas you may have to improve the mock to better
support your use case
On Sat, Apr 10, 2010 at 8:35 PM, Pavel pag...@gmail.com wrote:
Hi,
I'm fine with +/- 10%, but perhaps with my massive examples I shifted the
focus away from the original issue:
Route throttler is configured for 7 messages per second, but mock endpoint
will match message count of 7, or 14, or anything in between.
Thus the closest test I can do to verify intended limit of 7/second is
targetMock.expectedMinimumMessageCount(15);
targetMock.setResultWaitTime(1000);
...
targetMock.assertIsNotSatisfied();
... which is +/- 114%, and value of such test is questionable.
And I'm trying to figure out which of the following is the case
1. My code or test is incorrect
2. There is an issue with throttler
3. There is an issue with mock endpoint
4. Mock endpoint by design is not the right tool for the job
If #3 or #4, I'll need different approach to testing. Otherwise
implementation needs to be changed.
Thanks,
Pavel
On Sat, Apr 10, 2010 at 7:04 PM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
You can newer trust 100% on System time millis as its not accurate. So
make assertions on a given +/- delta.
On Sat, Apr 10, 2010 at 5:27 PM, Pavel pag...@gmail.com wrote:
Tried that, and noticed a few differences. maximumRequestsPerPeriod is 7.
* Expected message count 7 consistently fails with Expected X, but
was
7
* Expected message count 7-11 passes
* Expected message count 12,13 seems racy: sometimes test would fail with
Expected X, but was X+1
* Expected message count 14,15 passes (or I simply did not catch races).
* Expected message count 16-18 is racy again, e.g. Expected 17, but
was
19
* Expected message count 30 is racy, e.g. Expected: 30 but was: 32
That is not 100% precise, as I was giving limited number of tries for
each
case.
BTW, camel 2.2.0, activemq-camel 5.3.1.
Thanks,
Pavel
On Sat, Apr 10, 2010 at 2:31 PM, Claus Ibsen claus.ib...@gmail.com
wrote:
Hi
Can you try with
targetMock.assertIsSatisfied(1000);
On Sat, Apr 10, 2010 at 11:43 AM, Pavel pag...@gmail.com wrote:
Hello,
I'm facing strange behaviour of throttler + mock endpoint when route
under
test is this:
camel:route
camel:from uri=activemq:A/
camel:transacted/
camel:throttle timePeriodMillis=1000
maximumRequestsPerPeriod=7
camel:to uri=activemq:B /
/camel:throttle
/camel:route
test itself defines producer for direct - activemq:A route, as well
as
activemq:B - targetMock route, and then does this:
targetMock.expectedMessageCount(7);
targetMock.setResultWaitTime(1000);
for(int i=0; i40; i++)
{
producer.sendBody(Message + i);
}
targetMock.assertIsSatisfied();
This passes.
*BUT* if I change targetMock.expectedMessageCount(7); to e.g.
targetMock.expectedMessageCount(11); it passes as well!
Looks like test would pass if expectedMessageCount is anything between
[maximumRequestsPerPeriod, 2* maximumRequestsPerPeriod].
I tested various expected message counts against
maximumRequestsPerPeriod=7
3: Expected: 3 but was: 7
4: Expected: 4 but was: 7
5: Expected: 5 but was: 7
6: Expected: 6 but was: 7
7: passed
8: passed
9: passed
10: passed
11: passed
12: passed
13: passed
14: passed
15: Expected: 15 but was: 14
16: Expected: 16 but was: 14
17: Expected: 17 but was: 14
18: Expected: 18 but was: 14
19: Expected: 19 but was: 14
20: Expected: 20 but was: 14
... and against maximumRequestsPerPeriod=3
2: Expected: 2 but was: 3
3: passed
4: passed
5: passed
6: passed
7: Expected: 7 but was: 6
8: Expected: 8 but was: 6
9: Expected: 9 but was: 6
10: Expected: 10 but was: 6
Can you please explain that? Is it some sort of mock endpoint
specifics?
I'd like my test to be fairly strict, as the goal is to verify that
route
meets SLA...
Thanks,
Pavel
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Null parameters when routing CXFRS endpoints
I think you can't have more than 1 resource class to create a right proxy as
i have investigated the code and CxfRsEndpoint only sets the first
resourceClasss upon setting up of JAXRSClientFactoryBean
Here:
protected void setupJAXRSClientFactoryBean(JAXRSClientFactoryBean cfb) {
// address
cfb.setAddress(getEndpointUri());
if (getResourceClasses() != null) {
cfb.setResourceClass(getResourceClasses().get(0));
}
}
This will affect on the reflection part in invokeProxyClient:
Method method = findRightMethod(sfb.getResourceClasses(), methodName,
getParameterTypes(parameters));
It will only get 1 resource class to get the right method.
Jejo
willem.jiang wrote:
I don't think current Spring DSL support to set the Object[] into
header. I'm afraid you need to use processor or Java DSL to do this job.
Willem
jejmaster wrote:
Hi Willem,
Thats another good feature. But how do you set the Object[] varValues on
CxfConstants.CAMEL_CXF_RS_VAR_VALUES message header via spring xml?
from uri=cxfrs://bean://rsServer/
!-- We can remove this configure as the CXFRS producer is using
the
HttpAPI by default --
setHeader headerName=CamelCxfRsVarValues
?
/setHeader
to uri=cxfrs://bean://rsClient/
Or do I still need to create a processor bean class to manually set this?
Regards,
Jejo
willem.jiang wrote:
Oh. my mistake.
If you take a look at the CxfRsProducer.invokeProxyClient(Exchange
exchange), you will find you need to set
CxfConstants.CAMEL_CXF_RS_VAR_VALUES message header to set the varValues
if there are more than one resource class to create a right proxy.
Willem
jejmaster wrote:
I see. That's great. So you mean the serviceClass parameter is optional
when
configuring cxf? How do you expose the service without specifying the
serviceClass ? Isn't it required configuring at least the cxf:rsServer?
cxf:rsServer id=restRouter address=/restRouter/
serviceClass=com.project.service.impl.ServiceManagerImpl /
cxf:rsClient id=restEndpoint
address=http://localhost:8080/services/rest;
serviceClass=com.project.service.impl.ServiceManagerImpl /
route
from uri=cxfrs:bean:restRouter/
to uri=cxfrs:bean:restEndpoint/
/route
Jejo
willem.jiang wrote:
It's hard to create the Proxy without specify the ResourceClass.
HttpClient API is more friendly, as you don't need to specify the
ResourceClass when creating the client.
Willem
jejmaster wrote:
Hi Willem,
Its working enough in 2.3-SNAPSHOT. but we decided to use 2.2 as of
the
moment until 2.3 gets released.
Do you recommend on the httpclient rather than the proxyClient?
Jejo
willem.jiang wrote:
Hi Jejo
Please feel free to log a JIRA for it, doesn't the HttpClient work
good
for you ?
Willem
jejmaster wrote:
I found out that JAXRS Client only sends 1 parameter. So i will
just
have
to
configure my service class to only accept 1 parameter instead of
two.
Ill
just wrap it in a transfer object.
Anyway, maybe as a enhancement to camel-cxf jaxrs, hopefully we can
also
use
and support different rest clients such as Httpclient and URLStream
so
form
parameters can also be allowed.
Regards,
Jejo
jejmaster wrote:
Hi Willem,
I just used the TestProcessor to see the value of the
inMessage.getBody()
because even if there's no processor, the parameters really gets
null
when
routed.
I am digging the code right now at CxfRSProducer. And it seems
that
the
problem is in the Reflection part in the method invokeProxyClient.
Object response = method.invoke(target, parameters);
i have logged the parameters before this part and the values were
still
in
there.
I have also tried updating how JAXRSClientFactoryBean (cfb) is
used
as
a
jaxrs client.
Example:
BindingFactoryManager manager =
cfb.getBus().getExtension(BindingFactoryManager.class);
JAXRSBindingFactory factory = new JAXRSBindingFactory();
factory.setBus(cfb.getBus());
manager.registerBindingFactory(JAXRSBindingFactory.JAXRS_BINDING_ID,
factory);
Object targetClass = cfb.create(sfb.getResourceClasses().get(0));
Object response = method.invoke(targetClass , parameters);
Still, the parameters, gets null after this method.invoke(..)
reflection.
Im still digging on it and checking if i could replicate the
reflection
part. Can you also analyze/replicate it?
Thanks.
willem.jiang wrote:
Hi,
Can I see the code that you do in the testProcessor?
If you don't set the exchange.outMessage(), you should get the
right
parameter from the inMessage body.
Willem
jejmaster wrote:
Hello,
I am using the Camel 2.3-SNAPSHOT and implementing the CXFRS
routing
through
ProxyClient. I have setup my JAXRS Service Class method to
accept
2
parameters, a String and an Object. The service is working fine
when
i
am
invoking it directly but when i am using the cxfrs
Re: Restlet url encoding post data?
I'd be happy to contribute a fix. Let me take a closer look at it to see if there was a good reason for the encoding. I think it should do something similar to the http component, which allows you to set the content type for posts. Claus Ibsen-2 wrote: Hi We love contributions. So if you want to help out and provide a patch, that would be cool. I am sure restlet support posting data in different encodings. Could you create a JIRA ticket, and point out where the hardcoded encoding is in the camel-restlet component. On Sun, Apr 11, 2010 at 1:49 PM, Bee1000 richbo...@hotmail.com wrote: Using http does work, but it still seems like a bug to hard code the encoding of post data for restlet. I thought post data could be any text or binary data. It seems like this reduces the usefulness of the restlet camel component. Just out of curiosity, is there another reason why the encoding is hardcoded? (Perhaps to be more precise, the message body is being encoded in the RESTLET component, which for POST means that post data is being encoded.) willem.jiang wrote: Hi, I think you can try to use Camel-Http component, which is leverage common http client to invoke the http service. Willem Bee1000 wrote: I'm trying to post documents to couchdb using restlet but the restlet component is hard coded to url encode the post data. This makes the JSON text i'm posting invalid. Do I need to use some other component or is there a way around this? -- View this message in context: http://old.nabble.com/Restlet-url-encoding-post-data--tp28197024p28208067.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- View this message in context: http://old.nabble.com/Restlet-url-encoding-post-data--tp28197024p28209614.html Sent from the Camel - Users mailing list archive at Nabble.com.
JMS Transport for a CXF Rest Webservice... Is it possible using Camel?
Hi, I have been successful in exposing a SOAP based CXF webservice using JMS. Is it possible to do the same for a Rest based CXF Webservice? Can someone provide a working spring file snapshot? jaxws:endpoint id=jaxwsBlogServiceJms implementor=#blogWebService xmlns:blog=http://edu.ksu.ws/services; address=camel://jms:queue:BlogService serviceName=blog:BloggerService jaxws:features !-- Enables logging of SOAP messages. -- logging xmlns=http://cxf.apache.org/core; / /jaxws:features /jaxws:endpoint --Irshad Buchh -- View this message in context: http://old.nabble.com/JMS-Transport-for-a-CXF-Rest-Webservice...-Is-it-possible-using-Camel--tp28209700p28209700.html Sent from the Camel - Users mailing list archive at Nabble.com.
Recommended CSV component?
What is the best component to use for producing CSV (actually || separated) files? Is it bindy or flatpack? I had to add some features to the underlying commons CSV library for the CSV component in order to meet my needs. Namely, I added the ability to specify a String for the file field separator so you can use more than single character separators. I also added the ability to include a header line in the file and to specify the default value for null columns. I would be happy to contribute these changes back to Commons CSV, but that project has not been touched in a couple of years, so I thought there might be a better option. -- View this message in context: http://old.nabble.com/Recommended-CSV-component--tp28209742p28209742.html Sent from the Camel - Users mailing list archive at Nabble.com.
need help with interceptor in camel 1.6.2 using custom predicate
I am trying to intercept an exchange using a custom predicate and I am
having trouble re-routing the exchange or even simply stoping it.
Here is my routebuilder:
public class commentRoute extends RouteBuilder{
@Override
public void configure(){
intercept().when(isBlacklisted()).to(mock:intercepted).stop();
from(comment-queue).to(comment-catcher);
}
private Predicate isBlacklisted(){
return new Predicate(){
public boolean matches(Object ex) {
Exchange exchange = (Exchange)ex;
String email =
exchange.getIn().getBody(Comment.class).getEmail();
if(email.equalsIgnoreCase(jessesanf...@gmail.com)) {
return true;
} else {
return false;
}
}
public void assertMatches(String s, Object o) {
//do nothing
//this just satisfies the interface
}
};
}
}
I know that the predicate is being run because If I set a breakpoint at
if(email.equalsIgnoreCase(jessesanf...@gmail.com)) {
and step through the code from there the return true; is reached when i send
an exchange with the email address filled in with my email address.
Am I doing this all wrong? If this predicate is run and returns true why
doesn't camel respect my intercept re-routing or stoping?
Thanks so much,
jesse
Re: JMS Transport for a CXF Rest Webservice... Is it possible using Camel?
Does it make sense to use anything other than HTTP for rest? Rest depends on HTTP commands like GET, PUT, POST. These are not available in JMS. Can you explain what you want to achieve? Greetings Christian Am 11.04.2010 18:02, schrieb Irshad Buchh: Hi, I have been successful in exposing a SOAP based CXF webservice using JMS. Is it possible to do the same for a Rest based CXF Webservice? Can someone provide a working spring file snapshot? jaxws:endpoint id=jaxwsBlogServiceJms implementor=#blogWebService xmlns:blog=http://edu.ksu.ws/services; address=camel://jms:queue:BlogService serviceName=blog:BloggerService jaxws:features !-- Enables logging of SOAP messages. -- logging xmlns=http://cxf.apache.org/core; / /jaxws:features /jaxws:endpoint --Irshad Buchh -- Christian Schneider --- http://www.liquid-reality.de
Re: Restlet url encoding post data?
Have you tried setting the Content-Type header (to application/json) in your request Camel message? It looks like DefaultRestletBinding.populateRestletRequestFromExchange() method will add the header to the Form. If it does not work, any chance you are create a Jira with a testcase? A patch would be great, too. :-) Bee1000 wrote: Using http does work, but it still seems like a bug to hard code the encoding of post data for restlet. I thought post data could be any text or binary data. It seems like this reduces the usefulness of the restlet camel component. Just out of curiosity, is there another reason why the encoding is hardcoded? (Perhaps to be more precise, the message body is being encoded in the RESTLET component, which for POST means that post data is being encoded.) willem.jiang wrote: Hi, I think you can try to use Camel-Http component, which is leverage common http client to invoke the http service. Willem Bee1000 wrote: I'm trying to post documents to couchdb using restlet but the restlet component is hard coded to url encode the post data. This makes the JSON text i'm posting invalid. Do I need to use some other component or is there a way around this?
camel-example-etl and ant won't run
Hi Folks, I've found a couple of problems with camel-example-etl, at least with ant. Once I've downloaded dependencies and set environment variables the build fails with: C:\apps\apache-camel-2.2.0\examples\camel-example-etl\src\main\java\org\apache\camel\example\etl\CustomerTransformer.java:26: package org.springframework.orm.jpa does not exist This can be fixed by adding the following to the definition of sample.build.classpath in the build.xml file: path refid=spring.classpath/ ... but then we die with: Exception in thread main org.springframework.beans.factory.BeanDefinitionStoreException: Could not resolve bean definition resource pattern [META-INF/spring/*.xml]; nested exception is java.io.FileNotFoundException: class path resource [META-INF/spring/ The README.txt for camel-example-etl says: You can see the routing rules by looking at the java code in the src/main/java directory and the Spring XML configuration lives in src/main/resources/META-INF/spring ... but there is no src/main/resources/META-INF/spring directory, which would seem to be exactly the problem I've run into. Does anybody have the missing files? Anyway, I hope I've helped to make Apache Camel better :-) Cheers Kerry -- View this message in context: http://old.nabble.com/camel-example-etl-and-ant-won%27t-run-tp28213644p28213644.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: need help with interceptor in camel 1.6.2 using custom predicate
Hi Jesse
btw thanks for the kudo.
The interceptors in Camel 1.x is not working super duper.
And hence why they have been overhauled in the 2.0 onwards, which
would allow you to do what you want.
I suggest to search in the camel-core src/test/java directory for any
intercept unit tests and see if you can find an example that looks
like what you are doing.
I assume upgrading to 2.x is not an option. You may instead want to
use a Filter EIP in 1.x to build a solution where you can use the
predicate to include the good messages in the filter. Then the bad
messages can be skipped.
On Sun, Apr 11, 2010 at 11:11 PM, Jesse Sanford jessesanf...@gmail.com wrote:
I am trying to intercept an exchange using a custom predicate and I am
having trouble re-routing the exchange or even simply stoping it.
Here is my routebuilder:
public class commentRoute extends RouteBuilder{
�...@override
public void configure(){
intercept().when(isBlacklisted()).to(mock:intercepted).stop();
from(comment-queue).to(comment-catcher);
}
private Predicate isBlacklisted(){
return new Predicate(){
public boolean matches(Object ex) {
Exchange exchange = (Exchange)ex;
String email =
exchange.getIn().getBody(Comment.class).getEmail();
if(email.equalsIgnoreCase(jessesanf...@gmail.com)) {
return true;
} else {
return false;
}
}
public void assertMatches(String s, Object o) {
//do nothing
//this just satisfies the interface
}
};
}
}
I know that the predicate is being run because If I set a breakpoint at
if(email.equalsIgnoreCase(jessesanf...@gmail.com)) {
and step through the code from there the return true; is reached when i send
an exchange with the email address filled in with my email address.
Am I doing this all wrong? If this predicate is run and returns true why
doesn't camel respect my intercept re-routing or stoping?
Thanks so much,
jesse
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
