Queues do not provide timely access to error-response packets

[GoogleCodeExporter]

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?
- want to get response packets and critical exceptions

What version of the product are you using? On what operating system?
- 2.2 (the latest)

Please provide any additional information below.
- i modified the run method for the queue and i can get response packets
- please check my workaround...

    /**
     * <pre>
     * Run method for the "Queue Type" thread.
     * 
     * <B>Issue</B>
     *  : cannot get a response packet while using <B>queue</B>
     * 
     * <B>Note</B>
     *  : from miriele75@gmail.com
     * 
     * put
     * notificationManager.initializeConnection(server); and notificationManager.stopConnection();
     * into
     * while (mode == MODE.QUEUE) {} loop
     * </pre>
     */
    private void runQueue() {
        if (listener != null) listener.eventThreadStarted(this);
        try {
            int notificationsPushed = 0;
            while (mode == MODE.QUEUE) {
                notificationManager.initializeConnection(server);
                while (!messages.isEmpty()) {
                    busy = true;
                    ...
                    busy = false;
                }
                try {
                    Thread.sleep(10 * 1000);
                } catch (Exception e) {
                }
                notificationManager.stopConnection();
            }
        } catch (KeystoreException e) {
            this.exception = e;
            if (listener != null) listener.eventCriticalException(this, e);
        }
    }

Original issue reported on code.google.com by Four.Car...@gmail.com on 9 Feb 2012 at 3:45

[GoogleCodeExporter]

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.

Original comment by sype...@gmail.com on 9 Feb 2012 at 5:13

• Changed title: Queues do not provide timely access to error-response packets
• Changed state: Accepted

[GoogleCodeExporter]

Original comment by sype...@gmail.com on 21 Feb 2012 at 3:42

• Added labels: Milestone-2.3

[GoogleCodeExporter]

Fixed in r360 using solution #1 proposed in previous comments.

Original comment by sype...@gmail.com on 24 Feb 2012 at 3:52

• Changed state: Fixed

[GoogleCodeExporter]

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.

Original comment by Four.Car...@gmail.com on 29 Feb 2012 at 8:42

[GoogleCodeExporter]

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?  

Original comment by sype...@gmail.com on 29 Feb 2012 at 3:22

[GoogleCodeExporter]

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.

Original comment by Four.Car...@gmail.com on 29 Feb 2012 at 4:20

[GoogleCodeExporter]

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...  

Original comment by sype...@gmail.com on 29 Feb 2012 at 4:28

[GoogleCodeExporter]

        List<PushedNotification> llPushedNotiResult = null;

        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.

Original comment by Four.Car...@gmail.com on 29 Feb 2012 at 5:17

[GoogleCodeExporter]

Could you attach (not copy-paste) a copy of the full log output?

Original comment by sype...@gmail.com on 29 Feb 2012 at 5:21

[GoogleCodeExporter]

FYI, JavaPNS 2.3 Alpha 4 (released today in the Trunk) includes a fix related 
to this issue.

Original comment by sype...@gmail.com on 6 Mar 2012 at 3:29

[GoogleCodeExporter]

i checked this issue with newly released JavaPNS.
it works ok now.

thanks for your support.

BR,
Miriele

Original comment by linkzen....@gmail.com on 30 Mar 2012 at 2:23

[GoogleCodeExporter]

Excellent, thank you for the feedback!

Original comment by sype...@gmail.com on 30 Mar 2012 at 2:43