I'm using XEP-136 for message archiving in a chat system, when the user types his text, it will be displayed in the chat conversation for both users, and it will be automatically archived for further retrieving.
But when reloading the chat window, and re-connecting to the xmpp server (openfire), the last message won't be shown until one minute or more.
That means, the message won't be fully archived immediately.
Are there any settings in openfire that I must check out first? or do I have to try something other than message archiving?
This is my "retrieve collection" stanza (in strophe.js syntax) :
$iq({type: 'get'}).c('retrieve', {xmlns: 'urn:xmpp:archive', with : 'user#server',start:'13-10-28T16:30:00'}).c('set', {xmlns: 'http://jabber.org/protocol/rsm'}).c('max').t('100');
So far, The sending and receiving parts work great, the sole issue, is that when reloading page, messages less than 1 minute won't show up until reloading the page after another 1 minute.
it seems that messages take more than 1 minute before being archived.
Related
I have been using
Net::SSLeay
for 20 years to post data to authorize.net and receive the reply, as shown below:
($reply_data, $reply_type, %reply_headers) =
post_https($host, $port, $script, '', $form_data);
#data = split (/\,/, $reply_data);
$FORM{'x_response_code'} = $data[0];
$FORM{'x_response_reason_text'} = $data[3];
$FORM{'x_auth_code'} = $data[4];
$FORM{'x_amount'} = $data[9];
if ($FORM{'x_response_code'} != 1) {...
authorize.net received the data and processed the payment, but my system did not receive a reply. The user got a server error, and tried submitting the form several more times, all which resulted in payment processing, but no reply from authorize.net. When comparing my logs with authorize.net's processing time, I see that there's about a fifteen minute lag time between when the call was sent, and when authorize.net processed the payment. All four attempts were completed before the first processing occurred. Authorize.net says there were no problems or changes on their end.
How can I suppress the server error and instead return a custom error message?
As I understand it, your problem is that your local server is timing out before receiving a response from authorize.net, and from your log files, it seems that the response does arrive, but after a long delay. Although it is probably possible to configure your server to wait for longer before timing out (assuming you have control of the server config, etc.), 15 minutes is too long for a user to wait and would provide very poor user experience. Therefore, I'd suggest one of the following strategies:
submit the form by AJAX and wait for a response -- i.e. translate your form processing logic into javascript and perform the transaction asynchronously. Looks like there's an existing authorize.net JS API.
the old school method: when the form is submitted, fork a new process that posts the form data (e.g. using curl) and saves the response to a file. The UI would return an intermediate page informing the user that their payment is being processed, and would periodically check whether the response has arrived, either through a link the user clicks to trigger a test for the presence of the response file, or through automatically refreshing the page (but see these accessibility guidelines).
Whatever strategy you use, I would get in touch with authorize.net and see if you can find out why the response is taking so long. Adding a note to users that indicates that there have been delays recently and preventing them from submitting the same payment four times in a row would also definitely be good!
I have a simple application using firebase. You login and it takes you to a chatroom / channel board where you can select the topic you would like to post in.
Everything works perfectly, writes to firebase, updates the message board.
The issue comes in after you post in one topic, back out (segue) and then select a different or same topic to post in. It duplicates (or triplicates depending on the number of times you exist and go back in) on the message board, but only writes to firebase the one time.
I tried to messages.removeAll() on Load, but it did not help.
Thank you,
I can offer more help if there are some code but from your problem I think the reason is you did not clear observer before back out of topic. Something like this:
conversationReference = Database.database().reference().child("conversations/{conversationId}")
//observe messages ...
//then before moving out
conversationReference.removeAllObservers()
We use the cumulocity REST API. Regular real time notifications work, e.g. we subscribe to /alarms/*, start our connection/polling loop and when we create an alarm we receive the expected JSON. We did not install any specific modules or statements, it just works.
But when we try to do the same with SmartREST we receive this error, as soon as the alarm is created:
40,,/alarms/177649296,Could not find any templates subscribed for the channel
Following the reference guide (http://cumulocity.com/guides/reference/smartrest/) we tried it like this, where all requests have the same X-Id-header and all requests result in the expected http status 200 and no error messages, except for the last one:
Register a smart response template by doing a POST to /s
Body: 11,102,,,$.channel
Handhake: POST to /cep/realtime
Body: 80
Response is our clientId (e.g. 191het1z38bp7iq1m96jqqt8jnef)
Subscribe: POST to /cep/realtime
Body: 81,191het1z38bp7iq1m96jqqt8jnef,/alarms/*
Connect: POST to /cep/realtime
Body: 83,191het1z38bp7iq1m96jqqt8jnef
In the normal REST case the notification consists of a JSON array with 2 elements, both of which have a property "channel". So that is what we would expect from our response template. Instead, we get the aforementioned error 40.
Is our response template wrong? Is it not properly matched by the X-Id? What does it mean, that there are no "templates subscribed for the channel"? The subscriptions are done for a clientId, and not for a specific response template, and the templates are supposed to be matched automatically anyway. So probably "template" means "X-Id" here? The documentation seems ambiguous as to the meaning of that word. But anyway, we did use the same X-Id header in all of the requests.
Any pointer about what we're doing wrong would be appreciated, since we tried pretty much anything by now.
The SmartREST protocol was developed for a IoT-device <-> platform communication. So there was never any design around using it to subscribing to realtime data (except of course for the operations a device needs) as usually devices to not need subscribe to the data that they created themselves.
That said it is possible to use it but with a couple of limitations. Your approach is basically correct but there is one problem with the subscription. The wildcard subscriptions will not work with SmartREST because on subscription it links your X-Id with the channel you subscribed to but there is never a message published on the channel /alarms/*. Thus this kind of weird error message that said that there was no template subscribed for the channel the alarm appeared on. Inside CometD you still receive the alarm because of the wildcard subscription but the SmartREST part does not work.
The messages are published on the channel with the deviceId (e.g. /alarms/12345).
If you subscribe to /alarms/12345 it will work. You can of course subscribe to as many channels as you want but wildcard subscription won't work.
Regarding the templates you need to know the following. The SmartREST parsing is not done on the raw JSON of CometD but on the payload inside it (e.g. the alarm). So a template for an alarm could look like this:
11,500,,$.severity,$.id,$.type,$.severity
This would trigger only if the object has a severity and would return id, type and severity.
I am working on a chat application and want to add "last seen at" functionality. I am trying to implement it by using presence stanzas but getting one issue, please check at below link
Not getting unavailable presence of User A when User B is also unavailable
Is there any other way to implement last seen at functionality
please suggest
The first Google result for "xmpp last seen" is XEP-0012: Last Activity, which is a protocol extension that can be used to find out when a user was online last time.
You send a request like this:
<iq from='romeo#montague.net/orchard'
id='last1'
to='juliet#capulet.com'
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
And get a response like this:
<iq from='juliet#capulet.com'
id='last1'
to='romeo#montague.net/orchard'
type='result'>
<query xmlns='jabber:iq:last' seconds='903'/>
</iq>
Which means that the contact was last online 903 seconds ago. Subtract this from the current time to get the "last seen" timestamp.
Last seen and Last Activity are two different scenarios.
Last Activity is when user gone offline last time, but last seen is when user goes in background from the application in that case user will be available if application is not killed.You have to create new plugin on server side for last seen.
The #legoscia solution will return the last activity time, which is your last logout time(not the last time when user was online), plz check this https://github.com/processone/ejabberd/issues/2265
If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty element whose 'seconds' attribute is set to a value of '0'.
One solution is to kill the session every time the app goes in background and reconnect when the app is in foreground
My Magento Verison is - 1.4.1.1
I am having two problems:
1) When I am going through various steps of Onepage checkout (registration, billing, shipping, and payment tabs), sometimes during this process I am redirected to the cart page. There is no error, no exception, no report gets generated in var/report. I dont know how to debug it. Aren’t there any logs I can look for?
2) In same Onepage Checkout process after clicking on place the order (last step) , some times it redirects to the cart page, sends an email saying that the order failed with the message:
Quote totals must be collected before this operation.
To resolve it I commented this line in prepareRecurringPaymentProfiles in the file magento/app/code/core/Mage/Sales/Model/Quote.php, which solved the problem:
throw new Exception("Quote totals must be collected before this operation.");
I dont know if these 2 problems are related or not. But I am not having the 2nd problem now but having 1st one quite frequent. What could be the reason and how to resolve it?
further update-I checked the firebug trace, It is 500 internal server error which comes sometimes in any of the step in one page checkout. I was able to dig down into savebillingaction, saveshippingaction functions in onepagecontroller.php and found that error comes when $this->getRequest()->isPost() is blank , If it is 1 then it goes ahead, and goes to the next step else it redirects to cart, No I dont know why this is not 1 or is it because ajax is not able to send post data but I checked XHR request, Ajax send the post data every time (checked with firebug extension). Can Someone tell me What I could do next to troubleshoot. Where I can look for these Ajax Calls?
Shipping.phtml (any step.phtml) has JS at the bottom , How does it call OnePagecontroller saveshippingaction function ?
Since it's internal server error, try to access the error log of the server. Will tell you where is the problem. I' ve had the same problem in 1.7.0. In my example the problem was at /app/code/core/Mage/Usa/Model/Shipping/Carrier/Fedex.php
For anyone else coming across the "Quote totals must be collected before this operation." error, check your Apache logs for the reason of the 500 internal server error. If it's something like this:
mod_fcgid: read data timeout in 40 seconds
Premature end of script headers: index.php
process 26126 graceful kill fail, sending SIGKILL
..PHP is taking too long to respond. Usually its the onepage/checkout saveOrder action because it's quite heavy and often needs to connect to third party services (payment gateways, newsletter services like mailchimp, etc.). These calls to third party services can take a while, depending on the network state and might be the reason of PHP timing out.
You can start by increasing the timeout, but it's not a good permanent solution because you want to find out why this is happening in the first place.
New Relic is a good tool to monitor these calls (and a good tool to monitor your Magento store in general).
Firstly, commenting an error message is almost never the way to solve a problem, as you are just covering up some issue that may have severe consequences for your system.
Nailing down errors like this can be hard, but there are a few places to look first:
Did you install this system on a lower version and then upgrade? If so, how?
Are you using any extensions that modify the sales/checkout portion of the site?
Have you overridden any of the models concerned with this part of the site?
Have you changed the JS or HTML for the checkout?
If one of those is the case, you should review those changes for bugs. If not, try turning on the default theme for the site and checking out again. If the bug disappears, there is a problem with the theme that you are using. If it still appears, the problem is in code.
In that latter case, use Firebug to verify that the offending page requests result in Magento sending back "redirect" commands to the frontend. If that isn't the case, it may be some kind of JS error, but more likely you are ending up with invalid data in the system somewhere that causes Magento to choke during checkout.
Also (just thought of this, haven't tried it), try the multi-address checkout. As I recall, it uses regular page posts, and may even have more useful messaging than the OnePage checkout. Please edit your post with your findings from the above so that we can help more if that doesn't do it.
Hope that helps!
Just in case someone gets the "Quote totals must be collected before this operation." error, and none of these solutions fixes their particular problem, I'll mention that mine was an issue with this:
skin/frontend/base/default/js/opcheckout.js
var params = Form.serialize(payment.form);
There was a JS error unique to this site which was clearing the Payment form and preventing JS from reading it's contents. The module or theme that you use will differ, but check to make sure that the payment form can serialize correctly. If not, then that could be your problem.
I had the very same problem on my store Princessly:
It takes about 20 to 130 seconds or even longer for "Submitting order information ..." to go through and redirect to the payment gateway such as PayPal, if at all, after clicking the Place Order button, last step of one page checkout.
If it doesn't go through, very probably because something timed out since it took too long, it will redirect back to shopping cart, leaving the customer an empty cart and a Pending Payment order, OR, it will give the exception of:
Quote totals must be collected before this operation.
Since obviously, well, something timed out and the script ends before quote totals are collected (which is just my theory), thus sending the Payment Transaction Failed Reminder email.
After 12 hours of research and debug, I finally found the culprit and the solution.
Magento enables RSS stock and new order notification by default, so every time Place Order is pressed ('sales/order' resources are then saved), cache is refreshed so RSS will be published. Cache cleaning can be very time-expensive for Magento. Therefore the solution is simple. Just disable RSS notification for save of 'sales/order' resources.
Find /app/code/core/Mage/Rss/etc/config.xml and locate this block:
<sales_order_item_save_after>
<observers>
<notifystock>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterNotifyStock</method>
</notifystock>
</observers>
</sales_order_item_save_after>
<sales_order_item_save_after>
<observers>
<ordernew>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterOrderNew</method>
</ordernew>
</observers>
</sales_order_item_save_after>
Simply remove or comment it out and refresh Magento cache in System => Cache Management => Select All => Submit.
Now it only takes 1 second or even less for my store to go through Place Order and redirect to payment gateway.