Closed mwkirk closed 11 years ago
From sype...@gmail.com on February 09, 2012 17:13:18 Your proposed solution is going to open and close connections every 10 seconds, which is not desirable at all.
I think there would be two solutions to solve this:
1) Force a connection restart in the getCriticalExceptions() and getPushedNotifications() methods so that the queue has a chance to read the error-response packets (if any).
2) Design a separate thread that will monitor the queue's input stream asynchronously for incoming error-response packets, so not to block the queue itself.
I think the first solution will be the easiest to implement and the most reliable. The second one might be tricky, as users might invoke getPushedNotifications() before the monitor thread has had a chance to read the error-response packets...
I am pushing this to the next milestone, with a preference on implementing solution #1.
From sype...@gmail.com on February 24, 2012 03:52:08 Fixed in r360 using solution #1 proposed in previous comments.
From Four.Car...@gmail.com on February 29, 2012 08:42:07 thanks for your support.
i apply 2.3 alpha release on my project and test it with dummy device token. but i still get ok message for all requests.
i found that we couldn't exit the wile code block, even all requests are sent. (same as before)
please check it again.
BR, Miriele.
From sype...@gmail.com on February 29, 2012 15:22:15 Have you tried your dummy token with a simple Push.alert method? Maybe Apple doesn't even return an error-response packet for your token some some reason. There are many factors that will affect how (if) Apple will report an error for a given token. If you believe that the queue should be returning an error, please attach a copy of the full log output from your attempts so it can be analyzed.
As for: « we couldn't exit the wile code block, even all requests are sent.(same as before)», there hasn't been any change related to stopping a queue... so I do not understand why you would expect it to be the case now.
I am wondering, are you opening a Queue, pushing a list of notifications, and wanting to close the queue immediately after? If so, why use a queue at all?
From Four.Car...@gmail.com on February 29, 2012 16:20:25 yes, i've tried my dummy token with a simple push.alert and it works fine. well.. i don't want to close connection if i could get error response packet. but as i mentioned..i couldn't get it.
because making error response packet list routine is in the notificationManager.stopConnection();
so it never run the routine if exit the while loop that's why i modified like below..
while (mode == MODE.QUEUE) { notificationManager.initializeConnection(server); while (!messages.isEmpty()) {
...
} notificationManager.stopConnection(); }
it does not close the threads...just stop the connections...i think :) if there's a way to have error response packet without stopConnection(), please tell me how do i get it.
thanks for your kindness.
From sype...@gmail.com on February 29, 2012 16:28:01 Just to make sure I understand, what happens when you call queue.getPushedNotifications() which I specifically modified in r360 to address this issue? That method is now supposed to handle the connection restart necessary to get the error-response packets...
From Four.Car...@gmail.com on February 29, 2012 17:17:08
List
llPushedNotiResult = m_insPushQueue.getPushedNotifications();
for(int nPushedNotiCount = 0; nPushedNotiCount < llPushedNotiResult.size(); nPushedNotiCount++)
{
String strClientIdentifier = null;
PushedNotification insPushedNotiResultItem = null;
insPushedNotiResultItem = llPushedNotiResult.get(nPushedNotiCount);
strClientIdentifier = insPushedNotiResultItem.getDevice().getToken();
if(insPushedNotiResultItem.isSuccessful())
{
System.out.println("sending item is successfully done : DeviceKey = " + strClientIdentifier);
}
else
{
Exception exception = null;
int nStatus = 0;
exception = insPushedNotiResultItem.getException();
if(null != exception)
{
if(exception instanceof ErrorResponsePacketReceivedException)
{
ResponsePacket packet = ((ErrorResponsePacketReceivedException) exception).getPacket();
nStatus = packet.getStatus();
if( PushManager_APNS_Exceptions.eAPNS_EXCEP_NO_ERROR_ENCOUNTERED.getCode() == nStatus
|| PushManager_APNS_Exceptions.eAPNS_EXCEP_NONE.getCode() == nStatus
)
{
System.out.println("sending item is successfully done : DeviceKey = " + strClientIdentifier);
} else if(PushManager_APNS_Exceptions.eAPNS_EXCEP_INVALID_TOKEN.getCode() == nStatus) { System.out.println("sending item has an error : DeviceKey = " + strClientIdentifier + "Error Message = " + PushManager_APNS_Exceptions.eAPNS_EXCEP_INVALID_TOKEN.getDescription());
this is part of my code... and every including invalid dummy device token pushed notification returns true in the 'if' statement.
From sype...@gmail.com on February 29, 2012 17:21:29 Could you attach (not copy-paste) a copy of the full log output?
From sype...@gmail.com on March 06, 2012 15:29:07 FYI, JavaPNS 2.3 Alpha 4 (released today in the Trunk) includes a fix related to this issue.
From linkzen....@gmail.com on March 30, 2012 02:23:39 i checked this issue with newly released JavaPNS. it works ok now.
thanks for your support.
BR, Miriele
From sype...@gmail.com on March 30, 2012 02:43:59 Excellent, thank you for the feedback!
Original author: Four.Car...@gmail.com (February 09, 2012 03:45:10)
What steps will reproduce the problem? 1.make some payloads including invalid device token
2.use sample code to send them : private static void test_Issue87(String keystore, String password, String token, boolean production) {}
3.check that you can get response packets
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
please check my workaround...
/**
Original issue: http://code.google.com/p/javapns/issues/detail?id=105