Entity Sync Overwriting Data with Nothing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Entity Sync Overwriting Data with Nothing

porkiey
We are currently deploying OFBiz in multiple locations (USA, Hong Kong and China) but when the remote servers try and sync via push with the master server it looses the shipment receipt info and only the primary key exist, all other fields are empty. Then when the pull is invoked from the master to the remote servers empty data is overwritten into the fields where data was.

Here are the logs:
The log info:
2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4) [       GenericDAO.java:970:INFO ] Count select sql: SELECT COUNT(1)  FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?)
2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4) [       GenericValue.java:464:INFO ] Set [receiptId] to - SH26111
2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4) [      GenericValue.java:470:INFO ] Creating place holder value : [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)]
 
Anyone any ideas how to stop this happening?

Thanks
Sam
Reply | Threaded
Open this post in threaded view
|

Re: Entity Sync Overwriting Data with Nothing

David E Jones-3

You have the same records being sync'ed in two directions? Hmmm... I  
hope this is the only issue you run into.

Here's my guess about why this is happening:

1. during the first data move the record is not in place when it is  
referred to, so a dummy empty record is created
2. the dummy empty record has the current data/time stamped on it
3. in the second data move, opposite direction, that record is  
included as a new record with the timestamp when it was inserted which  
will be later than the timestamp of the original record, so when it  
goes in the other direction it will be considered the newer record and  
will therefore be used to overwrite the original record

I'll look in the code and see if this can be fixed in step #2 by using  
the timestamp of the referring record as the timestamp on the new/
dummy record. That should work, and if it doesn't then we'll just use  
that time minus something to make sure it is in the past. That  
shouldn't be necessary since this is happening because the record in  
question has a later timestamp so shows up later in the sorted records.

-David


On Jan 8, 2009, at 2:53 AM, Sam Hamilton wrote:

> We are currently deploying OFBiz in multiple locations (USA, Hong  
> Kong and China) but when the remote servers try and sync via push  
> with the master server it looses the shipment receipt info and only  
> the primary key exist, all other fields are empty. Then when the  
> pull is invoked from the master to the remote servers empty data is  
> overwritten into the fields where data was.
>
> Here are the logs:
> The log info:
> 2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4)  
> [       GenericDAO.java:970:INFO ] Count select sql: SELECT  
> COUNT(1)  FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?)
> 2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4)  
> [       GenericValue.java:464:INFO ] Set [receiptId] to - SH26111
> 2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4)  
> [      GenericValue.java:470:INFO ] Creating place holder value :  
> [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)]
>
> Anyone any ideas how to stop this happening?
>
> Thanks
> Sam

Reply | Threaded
Open this post in threaded view
|

Re: Entity Sync Overwriting Data with Nothing

porkiey
It seems that our local SVN server is corrupted and making a total mess of OFBiz so please ignore this thread.
If we still get the same problem later with a proper copy I will repost - thanks David!

Sam


On 09/01/2009 08:46, "David Jones" <[hidden email]> wrote:



You have the same records being sync'ed in two directions? Hmmm... I
hope this is the only issue you run into.

Here's my guess about why this is happening:

1. during the first data move the record is not in place when it is
referred to, so a dummy empty record is created
2. the dummy empty record has the current data/time stamped on it
3. in the second data move, opposite direction, that record is
included as a new record with the timestamp when it was inserted which
will be later than the timestamp of the original record, so when it
goes in the other direction it will be considered the newer record and
will therefore be used to overwrite the original record

I'll look in the code and see if this can be fixed in step #2 by using
the timestamp of the referring record as the timestamp on the new/
dummy record. That should work, and if it doesn't then we'll just use
that time minus something to make sure it is in the past. That
shouldn't be necessary since this is happening because the record in
question has a later timestamp so shows up later in the sorted records.

-David


On Jan 8, 2009, at 2:53 AM, Sam Hamilton wrote:

> We are currently deploying OFBiz in multiple locations (USA, Hong
> Kong and China) but when the remote servers try and sync via push
> with the master server it looses the shipment receipt info and only
> the primary key exist, all other fields are empty. Then when the
> pull is invoked from the master to the remote servers empty data is
> overwritten into the fields where data was.
>
> Here are the logs:
> The log info:
> 2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4)
> [       GenericDAO.java:970:INFO ] Count select sql: SELECT
> COUNT(1)  FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?)
> 2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4)
> [       GenericValue.java:464:INFO ] Set [receiptId] to - SH26111
> 2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4)
> [      GenericValue.java:470:INFO ] Creating place holder value :
> [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)]
>
> Anyone any ideas how to stop this happening?
>
> Thanks
> Sam



Sam Hamilton
CTO
Virtual Village

Tel: +86 (21) 6271 3051
Fax: +86 (21) 6271 3021
Mobile: +86 (135) 2451 4480
E-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Entity Sync Overwriting Data with Nothing

David E Jones-3

Sounds like another fun issue... source repos messed up are a pain!

Anyway, my guess is that what you described really IS an issue and  
I've changed some things in SVN rev 733423 that are more correct/
accurate in general and should fix this issue.

-David


On Jan 8, 2009, at 11:40 PM, Sam Hamilton wrote:

> It seems that our local SVN server is corrupted and making a total  
> mess of OFBiz so please ignore this thread.
> If we still get the same problem later with a proper copy I will  
> repost - thanks David!
>
> Sam
>
>
> On 09/01/2009 08:46, "David Jones" <[hidden email]>  
> wrote:
>
>
>
> You have the same records being sync'ed in two directions? Hmmm... I
> hope this is the only issue you run into.
>
> Here's my guess about why this is happening:
>
> 1. during the first data move the record is not in place when it is
> referred to, so a dummy empty record is created
> 2. the dummy empty record has the current data/time stamped on it
> 3. in the second data move, opposite direction, that record is
> included as a new record with the timestamp when it was inserted which
> will be later than the timestamp of the original record, so when it
> goes in the other direction it will be considered the newer record and
> will therefore be used to overwrite the original record
>
> I'll look in the code and see if this can be fixed in step #2 by using
> the timestamp of the referring record as the timestamp on the new/
> dummy record. That should work, and if it doesn't then we'll just use
> that time minus something to make sure it is in the past. That
> shouldn't be necessary since this is happening because the record in
> question has a later timestamp so shows up later in the sorted  
> records.
>
> -David
>
>
> On Jan 8, 2009, at 2:53 AM, Sam Hamilton wrote:
>
>> We are currently deploying OFBiz in multiple locations (USA, Hong
>> Kong and China) but when the remote servers try and sync via push
>> with the master server it looses the shipment receipt info and only
>> the primary key exist, all other fields are empty. Then when the
>> pull is invoked from the master to the remote servers empty data is
>> overwritten into the fields where data was.
>>
>> Here are the logs:
>> The log info:
>> 2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4)
>> [       GenericDAO.java:970:INFO ] Count select sql: SELECT
>> COUNT(1)  FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?)
>> 2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4)
>> [       GenericValue.java:464:INFO ] Set [receiptId] to - SH26111
>> 2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4)
>> [      GenericValue.java:470:INFO ] Creating place holder value :
>> [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)]
>>
>> Anyone any ideas how to stop this happening?
>>
>> Thanks
>> Sam
>
>
>
> Sam Hamilton
> CTO
> Virtual Village
>
> Tel: +86 (21) 6271 3051
> Fax: +86 (21) 6271 3021
> Mobile: +86 (135) 2451 4480
> E-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Entity Sync Overwriting Data with Nothing

Vince Clark
It has been a while since I used entity sync but I do remember that we definitely had issues with systems in different time zones where the system clocks were set to the local time. We solved it by setting all clocks to the same value and time zone, like GMT/UDT.

----- Original Message -----
From: "David E Jones" <[hidden email]>
To: [hidden email]
Sent: Saturday, January 10, 2009 11:54:38 PM (GMT-0700) America/Denver
Subject: Re: Entity Sync Overwriting Data with Nothing


Sounds like another fun issue... source repos messed up are a pain!

Anyway, my guess is that what you described really IS an issue and
I've changed some things in SVN rev 733423 that are more correct/
accurate in general and should fix this issue.

-David


On Jan 8, 2009, at 11:40 PM, Sam Hamilton wrote:

> It seems that our local SVN server is corrupted and making a total
> mess of OFBiz so please ignore this thread.
> If we still get the same problem later with a proper copy I will
> repost - thanks David!
>
> Sam
>
>
> On 09/01/2009 08:46, "David Jones" <[hidden email]>
> wrote:
>
>
>
> You have the same records being sync'ed in two directions? Hmmm... I
> hope this is the only issue you run into.
>
> Here's my guess about why this is happening:
>
> 1. during the first data move the record is not in place when it is
> referred to, so a dummy empty record is created
> 2. the dummy empty record has the current data/time stamped on it
> 3. in the second data move, opposite direction, that record is
> included as a new record with the timestamp when it was inserted which
> will be later than the timestamp of the original record, so when it
> goes in the other direction it will be considered the newer record and
> will therefore be used to overwrite the original record
>
> I'll look in the code and see if this can be fixed in step #2 by using
> the timestamp of the referring record as the timestamp on the new/
> dummy record. That should work, and if it doesn't then we'll just use
> that time minus something to make sure it is in the past. That
> shouldn't be necessary since this is happening because the record in
> question has a later timestamp so shows up later in the sorted
> records.
>
> -David
>
>
> On Jan 8, 2009, at 2:53 AM, Sam Hamilton wrote:
>
>> We are currently deploying OFBiz in multiple locations (USA, Hong
>> Kong and China) but when the remote servers try and sync via push
>> with the master server it looses the shipment receipt info and only
>> the primary key exist, all other fields are empty. Then when the
>> pull is invoked from the master to the remote servers empty data is
>> overwritten into the fields where data was.
>>
>> Here are the logs:
>> The log info:
>> 2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4)
>> [ GenericDAO.java:970:INFO ] Count select sql: SELECT
>> COUNT(1) FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?)
>> 2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4)
>> [ GenericValue.java:464:INFO ] Set [receiptId] to - SH26111
>> 2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4)
>> [ GenericValue.java:470:INFO ] Creating place holder value :
>> [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)]
>>
>> Anyone any ideas how to stop this happening?
>>
>> Thanks
>> Sam
>
>
>
> Sam Hamilton
> CTO
> Virtual Village
>
> Tel: +86 (21) 6271 3051
> Fax: +86 (21) 6271 3021
> Mobile: +86 (135) 2451 4480
> E-mail: [hidden email]