Recent changes to bugs

ReaderDevice.setTimeUTC is not working

2008-08-13T07:35:52Z

When set time utc, it reports succeed, but when get back the time utc, still the old time.

e.g.: if current time is 2008-09-13T15:32:56.283CST

try to set time to
3008-09-13T15:32:56.283CST

when get back, the time is still
2008-09-13T15:32:56.283CST

!8 RD.gH

2008-08-13T07:31:31Z

request:
!8 RD.gH

response:
!0 OK
ERR,2,ERROR_COMMAND_NOT_SUPPORTED,"Method not supported by object ReaderDevice."
>

I guess the reason is the LF is not correct for request, invisible characters

!78 RD.gM is not supported

2008-08-13T07:25:51Z

request:

!78 RD.gM

response:

>88:!0 OK
ERR,2,ERROR_COMMAND_NOT_SUPPORTED,"Method not supported by object ReaderDevice."
>

the request format is wrong, should be:

!78 RD.gMod

DataSelector.getAllTagFieldNames bug

2008-08-11T08:26:30Z

create TagField named "tf1"
create TagField named "tf2"
create DataSelector named "ds1"
add tf1 and tf2 to ds1
Call DataSelector.getAllTagFieldNames, the expected value is 2, but actual get 0

xml request sequences are as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>18</id>
<targetName></targetName>
<tagField>
<create>
<name>tf1</name>
</create>
</tagField>
</ns2:command>

<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>20</id>
<targetName></targetName>
<dataSelector>
<create>
<name>ds1</name>
</create>
</dataSelector>
</ns2:command>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>22</id>
<targetName>ds1</targetName>
<dataSelector>
<addTagFieldNames>
<fieldNames>
<list>
<value>tf1</value>
<value>tf2</value>
</list>
</fieldNames>
</addTagFieldNames>
</dataSelector>
</ns2:command>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>24</id>
<targetName>ds1</targetName>
<dataSelector>
<getAllTagFieldNames/>
</dataSelector>
</ns2:command>

at last we get the wrong response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:reply xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>24</id>
<resultCode>0</resultCode>
<dataSelector/>
</ns2:reply>

GetMaxNumberSupported bug of TagField

2008-08-11T07:40:01Z

TagField object should have method "GetMaxNumberSupported", this can not be seen from the command list in test client

If construct the xml request manually as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>10</id>
<targetName></targetName>
<tagField>
<getMaxNumberSupported/>
</tagField>
</ns2:command>

Then get response as follow:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:reply xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>10</id>
<resultCode>27</resultCode>
<error>
<name>ERROR_TAGFIELD_NOT_FOUND</name>
</error>
</ns2:reply>

However, GetMaxNumberSupported is a static method, if we keep <targetName> empty, reader should also be able to response correctly.

If you try following request, you will get the right response

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:command xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>10</id>
<targetName>defaultTagField</targetName>
<tagField>
<getMaxNumberSupported/>
</tagField>
</ns2:command>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:reply xmlns:ns2="urn:epcglobal:rp:xsd:1">
<id>10</id>
<resultCode>0</resultCode>
<tagField/>
</ns2:reply>

Is "defaultTagField" parameter a must???

heap space consumption

2008-03-10T10:00:54Z

- when the rp-proxy is used in a polling mode through the ale, the heap-space gets filled up.
- after a while, the tags do not come through anymore and apache tomcat crashes with a heap-space violation.
- cpu consumption goes up to 100% due to "failed" garbage collection.

- as can be seen on the two profiler screenshots (on the left), the heapspace gets filled up continuously. the peaks are after a polling cycle. no all of the allocated memory gets freed.
- the image on the middle shows the cpu consumption of the garbage collector.

Misinterpretation of TagField offset value

2007-11-07T12:46:19Z

The TagField offset value seems to be interpreted as bytes, but according to the Reader Protocol the offset is allways specified in units of memory bits.

Error in TagFieldValue handling

2007-11-07T11:31:57Z

The Reader Proxy adds an extra leading 0x00 byte to the data before sending it to the Reader.

Tag fields of dataselector not reported

2007-11-06T12:50:50Z

Tag fields added to a data selector are missing in the read report.

ReaderDevice.properties has to include default properties

2007-10-31T16:44:58Z

In the properties file ReaderDevice.properties of the reader-core default properties have to be specified even if they are not needed.