HistoryReaderImpl


#1

Hello Damian,

I was hoovering over the HistoryReaderImpl class and have a couple of minor remarks to make.

1) You seem to use the same event instance for every progress event. This could lead to race conditions for listeners that handle their progress events in a separate thread. I guess you could simply take all params necessary for the progress event constructor in the fire method and create the event inside it.

2) Some lines go over column 80

Concerning one, Yana mentioned that she had a problem with event dispatching of this event. I wonder whether this could have anything to do with it.

Yana are you handling such events in a separate thread?

Emil


#2

Emil Ivov wrote:

Hello Damian,

I was hoovering over the HistoryReaderImpl class and have a couple of minor remarks to make.

1) You seem to use the same event instance for every progress event. This could lead to race conditions for listeners that handle their progress events in a separate thread. I guess you could simply take all params necessary for the progress event constructor in the fire method and create the event inside it.

Will be fixed.

2) Some lines go over column 80

Not so much, but will be fixed.

But I had other problem with the history.
For the incoming messages and the records in the history there are two dates.
The first is the one coming from the protocol (in many cases is some how wrong)
The second is the one when the message is received on the client machine.

When retrieving records and passing them out of the MessageHistoryService here is the behavior of the service :
If the message has date (this is put for compability because in the first release of HistoryService there was only one timestamp )
this date is the timestamp of the MessageDeliveredEvent/MessageReceivedEvent if date is null the date of the receiving the message is put.
But some times this date is wrong For exmaple may be in the future. What happens when its in the future.
When reading records by date - the filename is used as timestamp and must be between the searched dates. So there is no such file
with future date so no messages are returned (but they exist). The same happens and if the date is just wrong.
As I wrote this I realize that when search for messages by date in given xml I compare the given dates with the timestamp of the received message on the client machine not the date that came from the protocol.

Everything became so messy . Any ideas ?

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

But I had other problem with the history.
For the incoming messages and the records in the history there are two dates.
The first is the one coming from the protocol (in many cases is some how wrong)

I've recently added a fix in OperationSetBasicInstantMessagingIcqImpl making sure that messages with a timestamp more than 24h away from the current time, will be fixed to contain the current date as a timestamp. Maybe this will reduce the number of wrongful messages.

I guess that you could do something similar. If I am not wrong, in the history files you store messages sequentially. So if, during a search, you encounter a message with a date that goes beyond the date of the next message you know something is wrong. In such a case you could replace it with a dummy date located (for example) 1 millisecond before the date of the message after it, or 1 millisecond after the message preceding it. You could even do the change in the file itself and store it, so that you don't come across the same problem every time you do a search.

How does this sound?

Emil

···

When retrieving records and passing them out of the MessageHistoryService here is the behavior of the service :
If the message has date (this is put for compability because in the first release of HistoryService there was only one timestamp )
this date is the timestamp of the MessageDeliveredEvent/MessageReceivedEvent if date is null the date of the receiving the message is put.
But some times this date is wrong For exmaple may be in the future. What happens when its in the future.
When reading records by date - the filename is used as timestamp and must be between the searched dates. So there is no such file
with future date so no messages are returned (but they exist). The same happens and if the date is just wrong.
As I wrote this I realize that when search for messages by date in given xml I compare the given dates with the timestamp of the received message on the client machine not the date that came from the protocol.

Everything became so messy . Any ideas ?

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Emil Ivov wrote:

I've recently added a fix in OperationSetBasicInstantMessagingIcqImpl making sure that messages with a timestamp more than 24h away from the current time, will be fixed to contain the current date as a timestamp. Maybe this will reduce the number of wrongful messages.

I guess that you could do something similar. If I am not wrong, in the history files you store messages sequentially. So if, during a search, you encounter a message with a date that goes beyond the date of the next message you know something is wrong. In such a case you could replace it with a dummy date located (for example) 1 millisecond before the date of the message after it, or 1 millisecond after the message preceding it. You could even do the change in the file itself and store it, so that you don't come across the same problem every time you do a search.

How does this sound?

Emil

I cannot see how does will fix the things with current wrong records and future dates.
I think that it is good all searches and shown dates in the history window(on the left of the window) to be done with the dates of the messages received on the client machine
and the use of the dates that came from protocol to be only when showing the actual messages (on the right of history window)

Is it ok ?

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Damian Minkov wrote:

Emil Ivov wrote:

I've recently added a fix in OperationSetBasicInstantMessagingIcqImpl making sure that messages with a timestamp more than 24h away from the current time, will be fixed to contain the current date as a timestamp. Maybe this will reduce the number of wrongful messages.

I guess that you could do something similar. If I am not wrong, in the history files you store messages sequentially. So if, during a search, you encounter a message with a date that goes beyond the date of the next message you know something is wrong. In such a case you could replace it with a dummy date located (for example) 1 millisecond before the date of the message after it, or 1 millisecond after the message preceding it. You could even do the change in the file itself and store it, so that you don't come across the same problem every time you do a search.

How does this sound?

Emil

I cannot see how does will fix the things with current wrong records and future dates.

Let's say that today the date is 10. We are running the sip-communicator and it hase opened a file named "10" where it stores messages that we're currently receiving and sending. Let's now imagine that a message arrives with date 1500. Earlier versions of the sip-communicator would have stored this message in file 10 but would have kept its date 1500. Let's now imagine that the next message that arrives has a correct date - 10 again. So in your file 10.xml you would have messages with dates 10, 1500 and 10, recorded in the order they were received. Am I right?

If this is the case then when you stumble upon such a record - with a date past the date of the message recorded after it, you could simply change its date to a date between the dates of the messages before and after it. Is this clearer now?

I think that it is good all searches and shown dates in the history window(on the left of the window) to be done with the dates of the messages received on the client machine
and the use of the dates that came from protocol to be only when showing the actual messages (on the right of history window)

Is it ok ?

Yes it's ok for you to do so from now on. What I suggest above is something that should take care of existing bad records.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi iana,
Something I just saw. Recently we add case in/sensitive search. The default behavior is case insensitive but I saw that the word that
was searched if is not the same case as the found one . The found word is not highlighted !

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Damian,

You're right. I have fixed that. You could try it now.

yana

Damian Minkov wrote:

···

Hi iana,
Something I just saw. Recently we add case in/sensitive search. The default behavior is case insensitive but I saw that the word that
was searched if is not the same case as the found one . The found word is not highlighted !

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net