I'm having trouble locating information on the http client connection pool- specifically for S3.
I've grep'd the code but no joy. Pointers would be appreciated.
As I suspected from looking at the code the Go SDK does not support client connection pooling similar to the Java SDK. From AWS Support:
I've heard back from our SDK team. They advise that concurrency management of the type that you're looking for is not provided out-of-the-box in our SDKs. You'll need to design and implement your own solution. For the Go SDK specifically, that means a semaphore pattern. Some links that may be helpful on that subject:
https://medium.com/#deckarep/gos-extended-concurrency-semaphores-part-1-5eeabfa351ce
https://aws.amazon.com/blogs/developer/context-pattern-added-to-the-aws-sdk-for-go/
The techniques described there should allow you to control the number of concurrent connections. I hope that helps. Please let us know if you have any additional questions.
Related
I'm upgrading from Tomcat8 to Tomcat9 and sendError does not pass the custom error message that I want to share with the consumer.
I read that sendError and org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER property is deprecated since Tomcat 8.5 but it seems like it works in Tomcat9 for some people.
Once this said then my main question is ... what is then the best way for a permanent solution on sending error messages when responding with error status code?
If the answer is that sendError is still compatible with Tomcat9 then my question is where this org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER should be configured? in which file? and in case it does not exists which is the code I need to add to the file to make it work? Because I found no entry in any of the files in my config directory for this property.
Thanks in advance
PS: I know that there are many posts for this topic but I'm afraid they are some old and/or some are based in Spring and this is not my case.
Amusingly sad question. As far as I can see, Tomcat developers feel that:
"because HTTP/2 doesn't support Reason",
"Reason is optional in HTTP/1.x and primarily intended for human use", and
"smart developer knows HTTP status codes already & doesn't need explanatory text"
They can just delete support for it.
From my perspective of protocol compatibility & systems integration, I think this is just astoundingly wrong. My perspective would be, that so long as HTTP/1.x is supported, all features of HTTP/1.x (whether a client "should rely" on these or not) should be supported.
My belief would be that it should be the overall system owner/ architect's decision -- encompassing the client & server applications, as well as Tomcat -- who makes the decision that they do or don't need Reason Codes.
Tomcat developers are not responsible for these overall systems and, from my perspective, should not be making decisions to delete commonly-expected features of protocols they claim to support which break what they are not responsible for.
However, that seems to be their decision.
http://literatejava.com/web/http-status-reason-broken-in-tomcat-9/
I have been putting this on the back burner as I had more immediate coding to tend to, but now I have arrived at a point where I need to use http live streaming (HLS) which is standardised by apple.
From the developer website's explanation, there is a set of CL tools to download and install on a server. Considering these are unix command line tools, I was wondering if I had to use a mac os server, which I don't have with me or any other server might do the job.
There are a lot of complicated steps to follow, but this is the basic one I would like to know. The rest is answered throughout SO, so I can handle that with the bookmarked links.
Any help greatly appreciated, or a link which I may have not found googling would be a great start.
Yes, unfortunately the HLS command line tools must be installed on a Mac.
What is your end goal? Are you trying to create, encode, and host your own videos? There are many services online that specialize in this, most of which support HLS out-of-the-box, such as https://www.brightcove.com
As a security professional I am curious to know if anybody is aware of security issues with the open source web conferencing product BigBlueButton and/or Mconf?
Thanks
Ron
I found this document: https://www.dropbox.com/s/jz7x1fglgawc8ef/BBB-MCONF-NOTES.pdf?dl=0 that describes what look to be some serious security problems. If this document is to be believed it might not be a good idea to use these applications.
According to this thread in which one of the core developers of BigBlueButton commented about security, https://groups.google.com/d/msg/bigbluebutton-dev/GzxfilVDpes/oCguFWyFEmUJ
He says:
"..there is no representation of security in BigBlueButton. None. We (the core developers) are not trying to build a secure web conferencing system." -Fred Dixon
Bob it appears that underlying intent & focus of BigBlueButton is not on security but rather capabilities. Perhaps there are ways to plumb in security aspects during or post-implementation efforts.
I've been looking at these too, both seem to provide fully functional XMPP servers in Java. I know Tigase is designed in a very modular way, not looked at Openfire in as much detail yet.
My intended use would be to create a custom IM-based app, using XMPP for convenience rather than to open my server up to talk to other XMPP servers.
I'm trying to evaluate my needs based on the following, roughly in order of importance:
Documentation coverage & community
How easy to plug in own functionality
Licensing/cost - I don't plan to release my code
Maturity and stability
Do not use Openfire if you expect to scale beyond a couple of thousand concurrent connections.
Tigase is amazing at handling hundreds of thousands concurrent connections and is wonderfully architected for largely distributed platforms where XMPP is simply the external interface. It comes with a price of rather poor documentation. You often need to go and read the source code to understand what's going on.
Openfire is perfect for small setups and its API is simple and very well documented. Unfortunately, it's not architected to scale even nearly close to what tigase is capable of.
Tigase is GPL(even version 3) licensed opposed to OpenFire being under Apache license ... for closed source application is OpenFire the go.
It is embaddable and proven to be reliable - 1000s of concurrent users. It even has gateways to communicate with legacy networks - like ICQ.
Only drawback I can se here is that it can handle only one domain per instance(port), however from your description that should not be a problem.
I totally agree with #Yuriy in that Tigase is great for high scalability whereas Openfire is more suitable for small, novice IT running chat for a SMB. I have gone into more detail on this in my blog on Tigase vs Openfire.
And Openfire 3.7.0.beta is out since some days now.
Lots of bug fixes, now also support Solaris as host system.
Concerning openfire ... it seems to be more or less abandoned and certainly not because of lack bugs to fix ;)
Is there a way I can make a request to a different server than the one that's being used for development using a RequestBuilder?
I keep getting
com.google.gwt.http.client.RequestPermissionException: The URL
http://127.0.0.1:4321/getSellers is invalid or violates the same-origin
security restriction
while I am sending request from 127.0.0.1:8888
GWT currently doesnt support cross domain ajax calls - but it can be worked around if you are willing to do a bit of jsni. And I heard a rumour some time ago that there is a gwt patch with the solution, but its not perfect. see this http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c/
to work around using jsni, you can use whats called the windows.name transport - see this blog http://www.sitepen.com/blog/2008/07/22/windowname-transport/ . i havent been able to locate a library for gwt to automate this, but i dont think its too hard to do yourself in jsni (and dont me misled by the blog being about dojo, its a general technique).
There is a detailed explanation on the topic of the Same Origin Policy and its consequences for developing with GWT here:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_SOP
The simple answer is: No, that's something that is disallowed for security reasons.
However, it should be possible to work around this limitation with all kinds of techniques (proxy servers, Yahoo Pipes, etc). As I'm no AJAX expert, I will leave the explanation of those to others.