J2ME client sends subscribes and unsubscribes in wrong order

[rsouissi]

Dear all,

In a mobile application I have, several items are being subscribed in a particular order. For instance:
- Subscribe item1
- Subbscribe item2 (which in the Data adapter depends on item1 being subscribed, otherwise it is rejected, there are some reasons for that)

What I noticed is that the client groups the requests together and sends them as once (below log shows "Serving multiple request") but the order is not as the code specified. It shows that item2 is being subscribed before item1 which actually causes some problems.

I also noticed that some subscriptions are sent multiple times (log below shows this item=TASI) eventhough the code calls subscribe(TASI) only once.

Questions: How to avoid this ?

Regards,
A

07 11:56:54,031 < INFO> Serving multiple request: /lightstreamer/control.txt?{6 subrequests} from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 1: LS_session=S2132784623N52&LS_window=1&LS_win_phase =0&LS_op=add&LS_mode1=MERGE&LS_id1=TASI&LS_schema1 =%28time%29%28s
tat_value%29%28stat_change%29%28stat_change_percen t%29&LS_snapshot1=true& from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 2: LS_session=S2132784623N52&LS_window=19&LS_win_phas e=0&LS_op=add&LS_mode1=MERGE&LS_id1=MBP.4010&LS_sc hema1=%28ask_mb
p0_price%29%28ask_mbp0_volume%29%28bid_mbp0_price% 29%28bid_mbp0_volume%29%28ask_mbp1_price%29%28ask_ mbp1_volume%29%28bid_mbp1_price%29%28bid_mbp1_volu me%29%28as
k_mbp2_price%29%28ask_mbp2_volume%29%28bid_mbp2_pr ice%29%28bid_mbp2_volume%29%28ask_mbp3_price%29%28 ask_mbp3_volume%29%28bid_mbp3_price%29%28bid_mbp3_ volume%29%
28ask_mbp4_price%29%28ask_mbp4_volume%29%28bid_mbp 4_price%29%28bid_mbp4_volume%29&LS_snapshot1=true& from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 3: LS_session=S2132784623N52&LS_window=18&LS_win_phas e=0&LS_op=add&LS_mode1=DISTINCT&LS_id1=Trades.4010 &LS_schema1=%28
trade_price%29%28trade_volume%29%28time%29%28trade _counter%29&LS_snapshot1=true& from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 4: LS_session=S2132784623N52&LS_window=17&LS_win_phas e=0&LS_op=add&LS_mode1=MERGE&LS_id1=4010&LS_schema 1=%28id%29%28ac
ronym_english%29%28name_english%29%28trade_price%2 9%28trade_volume%29%28price_change_percent%29%28pr ice_change%29%28stat_volume%29%28ask%29%28ask_quan tity%29%28
bid%29%28bid_quantity%29%28time%29%28stat_open_pri ce%29%28stat_min%29%28stat_max%29&LS_snapshot1=tru e& from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 5: LS_session=S2132784623N52&LS_window=8&LS_win_phase =0&LS_op=add&LS_mode1=MERGE&LS_id1=TASI&LS_schema1 =%28time%29%28s
tat_value%29%28stat_change%29%28stat_change_percen t%29&LS_snapshot1=true& from 127.0.0.1:4664
28.May.07 11:56:54,031 < INFO> Subrequest 6: LS_session=S2132784623N52&LS_window=16&LS_win_phas e=0&LS_op=add&LS_mode1=MERGE&LS_id1=TASI&LS_schema 1=%28time%29%28
stat_value%29%28stat_change%29%28stat_change_perce nt%29&LS_snapshot1=true& from 127.0.0.1:4664

[Mone]

Hi,
Sorry but presently subscriptions order is not guaranteed so that you can't afford on such order-logic to handle your subscriptions.

Note that in each subrequest where it is present the TASI item, the LS_window number is different. From a client-code point of view this means that each request pertains to a different SubscribedTableKey object, so it is strange that subscribe(TASI) was called only once. Please note that an onUnsubscribe call does not pertain to the state of a table related to the LSClient object but to the state of a table related to the server (so that if the client disconnects from the server you will receive an onUnsubscribe call but as soon as the client reconnects to the server that table will be re-subscribed to the server without any action needed).


Hope that helps.