We have a iOS app.We use HTTP services for getting and posting JSON data. Push notifications also enabled. If backend services are down is there any way to notify the user that services are down
did you try having a timout? if the app can't connect to the server for some time,
not only the connection attempt nearly always terminates, but it also raises a timeout exception on most of the programming languages I use.
try to check timeout specifications on the object you use to communicate via http, you're probabely able to implement them.
if you can't connect to the server in order to receive the http message
simply tell the user "server unavailable" or something like that.
ideally, if you know the backend server will be dead for a while (for
update purposes etc.) and you still can use the http server,
you may send an http containning text saying something like "server unavailable", or you may just send an empty message and then detect
it on the front end.(that is if you never send empty messages, anyways
I think it'll give you issues. "server unavailable" should be better.).
if the http server will be periodically unavailable, try something like implementing
update notifications. when you start up the app, the app asks when does a server
update will occur. and then you save it, and when it starts up again, it checks
whether or not such an update is happening at the moment.
besides that, if you really want to use push notifications and it'll
be periodically unavailable, before the server gets down - send a notification.
really you just need to use your imagination here.
but what you can't do - is send a notification when your server is down,
if you don't know it'll get down. mainly because you have no way of notifying the client (because the server you use for communication is down). however - as I stated above - what you can do is have the client checking for when the server is down(if it can't connect etc.).
if you have a backup server you can send a notification when the server gets down. if both the server and the backup server gets down, if only the backup server needs to inform you - the client will most likely won't know it's down.
you may use an external company to be your backup server. so if the electricity
is down (or something like that) it won't affect your notification system.
hope it helps.
Related
I want to implement long polling in a web service. I can set a sufficiently long time-out on the client. Can I give a hint to intermediate networking components to keep the response open? I mean NATs, virus scanners, reverse proxies or surrounding SSH tunnels that may be in between of the client and the server and I have not under my control.
A download may last for hours but an idle connection may be terminated in less than a minute. This is what I want to prevent. Can I inform the intermediate network that an idle connection is what I want here, and not because the server has disconnected?
If so, how? I have been searching around four hours now but I don’t find information on this.
Should I send 200 OK, maybe some headers, and then nothing?
Do I have to respond 102 Processing instead of 200 OK, and everything is fine then?
Should I send 0x16 (synchronous idle) bytes every now and then? If so, before or after the initial HTTP status code, before or after the header? Do they make it into the transferred file, and may break it?
The web service / server is in C++ using Boost and the content file being returned is in Turtle syntax.
You can't force proxies to extend their idle timeouts, at least not without having administrative access to them.
The good news is that you can design your long polling solution in such a way that it can recover from a connection being suddenly closed.
One such design would be as follows:
Since long polling is normally used for event notifications (think the Observer pattern), you associate a serial number with each event.
The client makes a GET request carrying the serial number of the last event it has seen, either as part of the URL or in a cookie.
The server maintains a buffer of recent events. Upon receiving a GET request from the client, it checks if any of the buffered events need to be sent to the client, based on their serial numbers and the serial number provided by the client. If so, all such events are sent in one HTTP response. The response finishes at that point, in case there is a proxy that wants to buffer the whole response before relaying it further.
If the client is up to date, that is it didn't miss any of the buffered events, the server is delaying its response till another event is generated. When that happens, it's sent as one complete HTTP response.
When the client receives a response, it immediately sends a new one. When it detects the connection was closed, it creates a new one and makes a new request.
When using cookies to convey the serial number of the last event seen by the client, the client side implementation becomes really simple. Essentially you just enable cookies on the client side and that's it.
I am working on an IMAP client application that connects to the mail server and loads the message headers into a list view.
In my application, it takes a long time to load. I've set it to connect and load the messages when I start the application.
I see that when other e-mail clients using IMAP load, all of messages are there instantly, even if there are 500 messages in the list.
How do they do it? Do they actually save the last list before the application was closed? Some other way?
Yes, email client apps usually cache downloaded messages locally for performance and then resync with the server periodically to resolve changes performed over time. In the case of IMAP, it can notify clients in real-time when emails are added/deleted/moved (Indy's TIdIMAP4 does not support that functionality yet, though), but you would have to resync manually at startup to account for changes that occurred while your app was not running.
Well...
I am working with an mobile application and a web server.
A characteristic of my web server is that it generates different set of data randomly. In other words, I cannot predict when the server will have ready data to send to the mobile app.
On other hand, the mobile app need to receive all data that the server generates. An approach could be request multiple times to get all these data. Indeed, It isn't a good approach, because I don't know when request the data.
If the mobile app could listen the server, after one start request or keep on the connection, for example, the server could sent any set of data in any time.
The question is: What is protocol suitable to this situation? How could I use that? Examples?
Thank you!
You could create a persistent TCP/IP connection to the server and permanently listen for incoming data (using a custom protocol or propably something websocket based). However such a permanent connection might seriously affect your battery life if it's for a mobile device. You will also lose the connection if the operating system automatically shuts down your application because it's out of memory.
The default approach to this problem are Push notification / Push services, where your server sends a notification about new data to a server of the phone provider (e.g. Microsoft or Apple push server), and this server sends the notification (as well as notificaiton from other online services) to your phone.
Some info for Windows Phone:
http://msdn.microsoft.com/en-us/library/hh221549.aspx
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558%28v=vs.105%29.aspx
Depending on how often you have new data both approaches can make sense.
WebSockets could be the answer: http://en.wikipedia.org/wiki/WebSocket
Specifically, for Windows Phone, there's a solution also: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558(v=vs.105).aspx
I am working on oracle SOA, I created a asynchrous connection and I was able to get the message that I was successful. Now as a client, how can I check if my service is working correctly. I am a newbie, any help would be appreciated.
As a client you don't. you can't, know the service is working. That is the, um, magic of SOA. You submit your request and just have to trust that the service will keep its side of the contact.
So, this service does something. Eventually. There must be some tangible output - an order placed, a password reset, a report generated. At that point the service should communicate the outcome to the client by some mechanism depending on the nature of your application and the service in question - probably email or SMS, but perhaps a record in a table or a generated web page.
This it really a design or architectural question. A Service is a process: there's a triggering action - the client's submission - and an outcome, which is what the client wants (or an exception). In between is a set of business sub-routines which are largely invisible to the client (although a long running service might have windows, like Amazon's order tracking service).
You need to design your service so that it communicates the outcome to the client in some fashion. The precise details will obviously depend on what your service does.
I have a question around biztalk and what happens when certain conditions around web service ports are met.
basically we have two applications - a main application (lets call it 'MainApplication') (containing the orchestration) and a web service application (lets call it 'MainApplicationWS'), where we expose a web service (created from biztalks web service tool) to take messages from wherever.
we have a testing tool which replays messages to the MainApplicationWS to simulate messages coming through from various external systems.
I have noticed that if we partial stop the MainApplicationWS application, and send messages through to the web service listed as a recieve location, nothing happens (obviously!) (also, the web service is still running, even though its been delisted as a recieve location). however, if i start up the MainApplicationWS again and bounce the host instances the messages are picked up from somewhere and played through to the orchestration and through to our application.
Im just a bit puzzled as to where its storing these messages while the MainApplicationWS is partially stopped. is the web service somehow hanging on to these? or does it still post through to the biztalk message box?
any clarification would be greatly appreciated :)
cheers,
adam
In short, I can't repeat your behaviour in Biztalk 2009. The closest to 'queueing' messages is if the orchestration is stopped but remains enlisted, such that messages are suspended resumable.
In long - I'm not quite sure what you mean by 'delisted as a receive location'. In Biztalk 2009:
Receive Locations can be enabled or disabled
Orchestrations can be stopped, and unenlisted
A Partial Stop on your BTS application disables receive ports and stops orchestrations (but doesn't unenlist them)
A full stop stops and unenlists orchestrations
The below is observed behaviour on BizTalk 2009 for a simple orchestration with a WCF Request/Response port, which receives a message, Maps the Send back to the same Port
The port is Direct Bound (MessageBox).
If the Isolated Host App Pool is disabled in IIS
A synchronous error is returned to the client - Standard IIS Error (503 Service Unavailable etc)
BizTalk receives no messages at all
If the BizTalk receive Location is disabled
WSDL: Syncrhonous error returned to the client - The Messaging Engine failed to register the adapter for "WCF-BasicHttp" for the receive location "xyz.svc". Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases
Service Call : The requested service, xyz.svc could not be activated. See the server's diagnostic trace logs for more information.
If the Orchestration is stopped, but not unenlisted
The received message is Suspended, resumable. The client times out (no response is issued).
If the orch is started and the message resumed, the message is then processed. The client will only get a successful reply if the orch start and the suspended message resume are done before the client's configured WS / WCF timeout.
If the Orchestration is unenlisted
The received message is Suspended, not resumable.
The client receives an error - The server was unable to process the request due to an internal error.
With the WCF CustomBinding it is also possible to listen directly on the relevant BizTalk ReceiveHost (i.e. no need for IIS at all to listen to BasicHTTP or WSHTTP, although we generally still use the Wizard generated svc in IIS solely for the hosting and publication of the WSDL. We then create a new WCF Custom receive location directly in BizTalk and point the client to this)
Hope this helps?