We are using sonic connect, rel 8.0.1, to submit documents via direct HTTP/S posting to the remote service. The remote service is not capable of handling "chunked" messages. Is there a way to configure the sonic connect service not to "chunk" messages.
Hi Tony!... I'm sorry I don't have a solution to your post, but I would like to ask you a question
that you might have an answer to, since it's "somewhat" related to your post... would you happen
to know the largest message size which SonicMQ is capable of handling?... I was told that the
upper limit is 10meg, and I would like to verify this... I've searched ALL OVER for the answer,
from the PEG, through Progress' knowledgebase and haven't been able to locate the answer...
please respond to: tbaxter@stec-inc dot com (I think entering an email into this post was
causing the "Post Message" to fail.)
It is 10 MB. I went looking for references in the doc and found the limit mentioned in Chapter 10 of the MQ Application Programming guide.
Note that the 10Mb limit referred to here is the default message size limit enforced by the SonicMQ broker. This limit can be changed via an advanced broker property (CONNECTION_TUNING_PARAMETERS.MAX_MSG_SIZE, ref' Progress SonicMQ Configuration and Management Guide). See Progress Solutions S10670 and S10671 for further info'.
That said, if you're pushing towards or beyond 10Mb (or at least a few 10's of Mbs) you should consider approaches for breaking up the messages in order to avoid introducing memory and performance issues on the broker and other components within the system. For example, SonicMQ provides 'Recoverable File Channels' (aka Large Message Support) as a more efficient means of dealing with very large messages.
In the context of ESB, be aware that when XML data is parsed for further processing inside an ESB container this may require far more memory than the original text form of the message; and the ESB container may be handling many of these messages simultaneously.
Thank you Terry for asking the related question, that was going to be my next investigation.
Thank you Maria and Paul for answering the related question.
Back to my acutal question. I opened a case with support, which still open at the moment, but i was put on the right path and have a working solution.
1) In SC Editor (in Work Bench), click on the config/spring.xml link 2) In spring.xml editor, add the namespace definition at the top. xmlns:http-conf="http://cxf.apache.org/transports/http/configuration" And scheme location: http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd 3) This is added immediately after the last element. It sets all outbound connections to not be chunked.
>I'm still waiting on a response from support before I close the case.These links explained the function of point 3 and how it relates to the sonic spring.xml file which also uses 'CAMEL'.
I'm still waiting on a response from support before I close the case.
These links explained the function of point 3 and how it relates to the sonic spring.xml file which also uses 'CAMEL'.
Your last post is exactly how to disable chunking in Sonic Connect.
Do you know how to specifically choose which outbound connection not to chunk, but let the other connections chunk if required?
It looks like you can specify matching pattern for outbound address or for WSDL port name. (source: http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html)
Exerpt from the wiki:
Another option for the name attribute is a reg-ex expression for the ORIGINAL URL of the endpoint. The configuration is matched at conduit creation so the address used in the WSDL or used for the JAX-WS Service.create(...) call can be used for the name. For example, you can do:
There are other examples on the wiki that show how to specfic WSDL port as conduit name. Here is one example.
those were the samples I found in my research as well. But because the spring.xml file uses CAMEL code for the endpoints, I don't know how to specify the what the conduit name should be.
I'm not even sure it can be done. One of the links I posted refers to this issue.
Are you invoking a Web Service or RESTful Service with Sonic Connect?
It's a RESTful Service with Sonic Connect.
Have you tried something this?
where "https://localhost:8443/.*" is the URL which can accept a regular expression
CXF conduit bean configuration can certinaly be injected by Spring (pls make sure the namespace is defined such as below).
If above does not work, please give this format a try.