-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathChangeLog
193 lines (157 loc) · 11.1 KB
/
ChangeLog
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
2010-06-28 Nima Kaviani <[email protected]> v.1.4.0
* JSON support added for viewing events, content, and state information. The extra
parameter should be added to the querying servlets in the form of "format=[FORMAT]"
and for now supports "xml" and "json". No "format" parameter would be interpreted by
the broker as the default format which is "xml".
* Caching now supports threading for automatic storage and retrieval
* Auto-start and auto-install scripts are added to the code for those who would like to
generate it from all the existing bundles. existing OSGiBroker bundles should still be
added manually but all the other libraries are installed automatically.
* The parameter "queryBase" can be used to determine whether the query should operate
based on the server time or the client time. queryBase equal to null or equal to
"server" would consider servertime for querying, while queryBase equal to client
considers client time for querying events
* An event attribute with the name timestamp is now considered as a reserved
attribute to be used by the client to timestamp the client time for the
event. This time stamp can be used to retrieve queries based on client timestamp
from the events provided by the clients. The value of timestamp should be
defined in milliseconds and is stored in the column `client_time` under eventlogs
table.
* event queries can be done based on client and server time. and using the following
attributes as parameters passed to the osgibroker/topic servlet (All the times
should be provided in milliseconds and an absolute time should be in the form of the
EPOCH time):
** start - the absolute starting or end time of the request, depending on the use of the 'beforeX' or 'afterX' parameter. If omitted means "now".
** beforeT - the relative starting time (i.e. before the start time)
** beforeE - the relative number of events (i.e. before the start time)
** afterT - the relative end time of the request for events
** afterE - the relative end time of the request for events
** end - the absolute end time of the request
** The parameters for frame-based query come in the following order.
*** non existence of the start parameter means NOW!
*** the priority for responding to the requests is as follows:
end > befreE > afterE > beforeT > afterT
That is, if more than one of the above parameters exist in the request,
the one with the higher priority is considered as the intention for the
query and is responded by the servlet.
** The use of the `querySize` parameter is deprecated as it can be modeled using
a `beforeE` parameter and the number of events to be retrieved without a `start`
time
* Database name now can be properly set from the configuration file and any arbitrary name can be selected.
* Uploading content is modified and is now working properly.
** The upload form can be accessed under HOST:PORT/html/upload.html
** The content then can be accessed under HOST:PORT/content/[contentid]
* The cache threading and storing issue is fixed so the timing is properly configurable through the configuration file
* The name for the host is fixed, so the network interface can be used in order to associate the
interface name to it with the default on set to "eth0"
* The publisher and the subscribers where implemented single threaded as a result a hanging
subscriber or a delayed client would delay the delivery of messages to all other clients.
The new release creates a CachedThreadPool for the clients requesting access to the delivery
of messages so the message delivery no longer gets hung up by the clients and the delivery
for different clients is served independent of the others.
2010-03-22 Nima Kaviani <[email protected]> v.1.3.2
* Default Password for the DB is changed
* UnsubscribeAll functionality added. This allows one client to unsubscribe from
all topics it is registered to. This is done by not specifying the name of the
topic that the client would like to usubscribe from. If the topic is NULL, the
client will be unsubscribed from all topics (Care should be given in using this
functionality).
* The Queue full issue fixed. The queue size for the received messages by a polling
client was set to be 1000. A client, idle for a long time, would render the queue
full. Now upon a queue full situation, the oldest message in the queue would be
replaced by a new one. The new queue size is 500.
* The problem with running out of heap memory is solved. The problem was due to having
lots of result sets unclosed when querying the database. The issue was fixed by
carefully closing all of them. DBCP supports a way to close the result sets and connections
and garbage collecting them automatically. This will be added in the later releases.
2010-02-03 Nima Kaviani <[email protected]> v.1.3.1
* The clients can query content elements or state elements of a topic
individually and by specifying the ID for the respective content or
state without having to poll for the entire state or content of a
topic. Same works for deleting the elements of content or state.
* NotificationTopics are added
** For each topic, "topicname", that a client registers to, the broker
automatically creates a notification topic with the following format:
"topicname__notification__".
** No client is allowed to subscribe to a NotificationTopic or post events
to the NotificationTopic. All messages published to a NotificationTopic
and all the clients subscribed under a NotificationTopic are internally
handled by the Broker. The clients can only poll the NotificationTopics
with notifications mainly on subscription/unsubscription events and
changes to the content or state of a topic.
** The Broker sends notifications to the NotificationTopic associated with
each topic, indicating changes (e.g., add, delete, update) to the content
of a topic or to the state attributes of a topic.
* Expiration for client subscriptions is added to the broker.
** During subscription to the /osgibroker/subscribe servlet, each client can
specify an "expires" parameter with its value specifying the number of seconds
before the client subscription expires. If no "expires" parameter is defined,
the broker assumes that the registration for the client will never expire.
** A new servlet named /osgibroker/keepAlive is added to the Broker. the
/osgibroker/keepAlive server is used to renew subscription of a client
with the broker. This servlet requires "clientID" and "topic" as its
mandatory parameters specifying the ID for the client and the topic
for which the subscription will be renewed. The servlet also accepts
an "expires" parameter, indicating the new number of seconds that the
client will remain subscribed with the broker after the latest call to
the /osgibroker/keepAlive servlet. A client that is initially subscribed
as a permanent client (i.e., without an "expires" parameter during its
subscription), can be changed to a temporary client by calling the
/osgibroker/keepAlive function for this client under the specified topic
and with an "expires" parameter and value defined for it. It is important
to note that, once a client becomes a temporary client, i.e., if the server
tracks its expiration, it is no longer possible to make the client a
permanent client and from there on, the subscription of the client should
be controled by the responsible client.
** In the /osgibroker/keepAlive servlet, in case a client is not subscribed
with the specified topic, or the client has already expired once the
/osgibroker/keepAlive servlet is called, the broker returns an error
response 417 (SC_EXPECTATION_FAILUE), with the following error message:
"No Client with this ClientID is alive".
** NOTE: It is important to mention that subscription expiratioins happen on
a per topic basis. That is, the client can define an expiration for
every topic that it registers to. If an expiration is defined for a
topic, it is the role of the client to make sure that renewals happen,
if necessary. The Broker will automatically unsubscribe the client
from a topic and its NotificationTopic upon expiration of its registration
time.
2009-11-19 Nima Kaviani <[email protected]> v.1.2.9
* Port Scanning for the Modem is done automatically. The Gateway gets plugged in,
and as soon as the installer gets turned on, the port scanner starts looking for
the modem gateway. If the modem gateway is detected, the modem gets hooked to the
broker and the broker start using SMS as a publisher.
* The SMS Installer is a lot more stable now. It automatically checks into the list
of bundles in the bundle context and detects which of the required functions for
running SMS is already installed. It installs the ones that need to be installed and
updates those that should be updated, and finally, starts those that need to starts.
Things happen a lot more smoother for a user.
* At the time of scanning ports, a progress bar is added to show what ports are being
scanned and how many more ports are remained to be scanned.
2009-10-14 Nima Kaviani <[email protected]> v.1.2.8
* A SMSInstaller bundle is added to the system that enables platform
specific installation of the SMS module and the required libraries.
* There is configuration file for the SMS module located in "configurations/services/"
that can be switched ON or OFF. If the switch is ON, the SMS modules and libraries will
be installed, if it is OFF, the module and the libraries will be uninstalled.
2009-10-7 Nima Kaviani <[email protected]> v.1.2.8
* The connection timeout issue for DBCP is solved. The connections no
longer get expired because of sitting idle in the pool for so long.
* The synchronization issue with multiple objects trying to access the
broker is solved. Using DBCP, each client is assigned its own
Connection object to connect to the DB and thus there is no need to
synchronize the connections.
* The serial port for the SMS module can be configured using the
properties file in the broker. The file is called
"ca.ubc.magic.broker.publisher.service.sms.SMSPublisherDS.properties"
* The configuration file for DBCP now can be configured to define the
parameters for DBCP connection eviction and eviction idle time in the
"ca.ubc.magic.osgibroker.storage.mysql.properties".
* The broker now comes with the WebConsole module, enabling
configuration of the broker to happen using the WebConsole without
having to deal with the command line. The WebConsole is accessible
from http://<your-host-name>:8800/system/console
2009-09-20 Nima Kaviani <[email protected]> v.1.2.7
* DBCP is now used for checking the connections
Copyright (c) 2009-2010 - The MAGIC Lab. University of British Columbia
Copyright and distirbution of this file, with or without modificatiosn are
permitted provieded the copyright notice and this notice are preserved.