I'm having trouble understand how WSO2 Proxy services are viewed.
I went through the tutorial to create and use the SimpleStockQuotesServices proxy service, and that went just fine.
Then I shut down the ESB, and started it up with sample 0 configured
(ie: ./wso2esb-samples.sh -sn 0) and that worked fine.
I started the backend axis server, and that worked fine too.
I ran the sample ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dprxurl=http://localhost:8280/ and it worked fine too.
Everything is great.
When I go to the admin console, and look at the list of deployed services https://localhost:9443/carbon/service-mgt/index.jsp?region=region1&item=services_list_menu
The page shows three services (echo, Version, and wso2carbon-sts). not the SimpleStockQuoteSercice that I was expecting. If I shut off the ESB, it all fails
My question, is, Where is it listed?
I guess that the ESB is just redirecting http://localhost:9000/services/SimpleStockQuoteService to http://localhost:8280/services/SimpleStockQuoteService, but I'm not sure, and I was really expecting to see the stock quote service. What's going on?
When I ran through the tutorial, I created a SimpleStockQuoteService, and when I started up sample set zero, I assumed that it would start up a similar SimpleSTockQuoteService on the ESB.
SimpleStockQuoteSercice is deployed inside the backend axis2 server and not inside ESB. What happens here is that ESB sits in-between the client and the backend axis server, mediating the messages.
In this sample, requests are sent to the ESB (http://localhost:8280/) and the ESB then sends them to the backend axis2 service (http://localhost:9000/services/SimpleStockQuoteService). You can find more info on the parameters used for this client here.
Related
I have a couple of IoT devices hosted on Thinger.IO and as part of their code execution from time to time they try to invoke thinger.io endpoints. This basically is their way of letting you connect with your business back-end services and handle IoT devices events.
It basically looks something like this:
as here at step 3 we make a reference to Thinger.IO's input resources. This basically lets your back-end to invoke functions on your IoT device. The issue that I am facing right now is related to step 2
My endpoints just stopped getting invoked. When I try to test the endpoint using their embedded client:
I get an error which is saying:
I don't really understand that. The last time an endpoint was invoked was on the 27th of February (5 days ago) and since then I've had my device completely turned off.
SIDE NOTE: The problem is not with my back-end because we can successfully invoke the endpoint using Postman.
Thee free cloud (community version) of Thinger.io has some rate limiters to throttle requests per user. However, it seems that you are not reaching those limits, so it should be a bug introduced in latest release 2.9.9 in Community Version. Will look into it. Thanks for reporting.
Edit: It should be fixed now in 2.9.91 version. Consider using a private cloud instance if you are connecting a couple of devices ;)
I have just deployed really first dev version of my api on my VPS to allow my frontend guy access it easily.
My setup is so far pretty simple - .NET Core 2.0 (API, JWT access control) + PostgreSQL.
Even for simple request with empty body to registration endpoint, I am getting response times about 100ms or even more. On localhost(not in Docker) it's much better - about 8-15ms for the same test.
Both application and db are in docker containers behind the nginx proxy on 4core/8gb VPS so it should not be an issue.
Some issue with docker configuration? I though it's something related to db, but as it's slow even on model validation when it does not call db at all it's something else...
I will appreciate any help...
I have encountered a strange issue while working with SignalR. It may be something I am doing wrong or an incorrect expectation on my part. I have posted the example code an issue description on git
https://github.com/boblautenbach/SignalRGroups
Thanks
-bob
OK, So I did some additional research. I found a SO q/a SignalR lost messages if IIS configure with more than 1 worker process that mentioned the same concerns and even though it wasn't related Azure, it was very relevant. If you have more than one instance of your Signalr hub Azure Web App, which can be set as seen below, then you will run into the issue I mentioned. Essentially, client connections made to instance A will not see instance B connections. If you do need more that one instance of your Hub, you will need to implement one of the scale-out options here http://www.asp.net/signalr/overview/performance/scaleout-in-signalr. I test this using the Service Bus scale-out option and it worked great (my site currently has 2 instances).
We have a secured & authenticated WCF service which cannot use service references. Thus, we provide the interface for the contracts and open client channel manually.
We have found out that as long we open it once, everything works fine. We can call several methods several times. However, if the channel is closed or just set to a new instance, the Login() (which happens to be required for first step prior to using the service), times out.
To make the matters even more mysterious, this only happens on our production server. If I run the same project locally, I am able to login many times as I want. Consuming the methods inside a web browser (even on a code-behind ASPX page) do not have this problem even with the production server. ONLY when it's a .NET client trying to open a client channel against the production server, do we have this problem.
We are not even sure where to start looking. Any advices would be greatly appreciated.
UPDATE:
As per #Rene's suggestion, we turned on logging on both sides. From client's log, there is a record of error which is basically the same timeout error we already got via the exception. Nothing meaningful. On the server's logs, there are records of service methods being invoked successfully even after 2nd login() and from server's POV, the request is served.
Additionally, I discovered that I could not even reproduce this issue on my machine using same test project to reproduce this problem. This reproduces on my developer's machine. I verified that we were at same version of .NET framework and Visual Studio. It has to be surely a client-side problem. What could be it?
In case anyone else is looking for answer, we finally found it -- the issue is due to the need to set on client's side System.Net.ServicePointManager.DefaultConnectionLimit to some higher value. The default value is 2 but in reality this allows only one proxy to be created and be usable. Setting it to 3 would allow 2 proxies to be created & be used.
I have a web application which fetches information from a web service. It works fine in our development environment.
Now I'm trying to get it to work in a customer's environment instead, where the web service is from a third party. The problem is that the first time the application tries to fetch information it cannot connect to the web service. When it tries again just seconds later it works fine. If I wait a couple of hours and try again, the problem occurs again.
I'm having a hard time believing this is a programming error, as our customer and the maker of the web service thinks. I think it has to do with one of the IIS or some security in the network. But I don't have much to go on and can't reproduce the error in our development environment.
Is it failing with timeOutException when you try to connect first time?. If yes, this could be the result on start up time of the service
I have a rule: "Always assume its your fault until you can demonstrate otherwise". After over 20 years, I still stick to it.
So there are therefore two cases:
The code is broken
There is a specific issue with the live environment
Since you want to demonstrate that the problem is (2) you need to test calls to the service, from the live environment, using something other than your application. Exactly what will depend on the nature of the web service but we've found SoapUI to be helpful.
The other thing that's not clear is whether you are making calls to the live service from your development environment - if, in testing, you're not communicating with the same instance of the service then that's an additional variable that will need to be considered (and I appreciate that you're not always given the option).
Lastly, #Krishna is right - there may be a spin up issue with the remote service (hence my question about whether you're talking to the same service from your dev environment) and -horrible as it is - the solution in the first instance may simply be to find a way to allow for this!
The error was the web service from the third party. The test stub we got to develop against was made in C# and returned only dummy answers. The web service in the customer environment actually connected to a COM object. The first communication with the COM object after a longer wait took almost a minute.
Good for me that the third party developers left the source code on the customer servers...