Hierarchies Job Failing The job process could not communicate with the dat

[Former Member]

Hi Experts,

We have a group of hierarchies that run as a separate job on the DS schedules. The problem is this when we schedule the job to run during the production loads it fails but when we run immediately after it fails it runs completely fine. So it basically means that if i run it manually it runs but when its scheduled to run with the production job it fails. Now the interesting thing is If i schedule the job to run anytime after or before the production jobs are done. It works fine.

The error i get is

The job process could not communicate with the data flow <XXXXXX> process. For details, see previously logged

error <50406>.

Now this XXXXX DF has only Horizontal Flatenning and it does not run as separate process because if i have it has separate process it fails with an EOF . So i removed the run as separate process and changes the DF to use in memory .

Any Suggestion on this problem...

[Former Member]

Sounds like your job server does not have enough memory for the dataflow and/or the dataflow requires a lot of resource. Can you provide details of DS version, OS, server spec, dataflow cache setting, memory compsumption by the failing dataflow?

[Former Member]

Thanks Mike.. I was hoping its a memory issue but the thing i don't understand is when the job is scheduled to run with the production job it fails. when i manually run the job during the production job it runs, this kinda baffles me.

DS 3.2 (Verison 12.2.0.0)

OS: GNU/LINUX

DF Cache Setting :- In Memory

processor : 0

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz

stepping : 4

cpu MHz : 2933.437

cache size : 12288 KB

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc ida nonstop_tsc arat pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm

bogomips : 5866.87

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management: [8]

processor : 1

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz

stepping : 4

cpu MHz : 2933.437

cache size : 12288 KB

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc ida nonstop_tsc arat pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm

bogomips : 5866.87

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management: [8]

Thanks for your help

[Former Member]

Have you tried changing the cache to pageable? I suspect the al_engine for the dataflow is memory hungry. Can it be simplified? For example, not all columns are generally needed to flatten a hierarchy, only the parent and child IDs, then can be joined back in a downstream dataflow.

[Former Member]

Thanks for the response Mike. I did run it with Pageable but that means it would run as a separate process even though the option is not checked. which would eventually cause me an EOF error. It have only Parent Id, Child Id and their corresponding description as attributes and thats about it. I need the desc to be a part of the list.

Let me try to schedule the jobs when there is no activity on the server and see what happens. Let me know if you have any more suggestions..

Thanks for your help

[Former Member]

<<I did run it with Pageable but that means it would run as a separate process>> This dataflow setting causes disk to be used as temporary memory cache for the duration of the dataflow, not to spawn a sub-dataflow.

[Former Member]

Thanks mike . Thats right... My first intention was to make the job run without a sperate process so I remove the option from the flattening transform. If I remove that check box the data flow should run in in memory for you to have only one process thread. if you remove the check box and run it in pageable cache it would actually consider the flattening to run as separate process which I did not want on the first place. Am I right here mike?

Let me know if I am wrong I can send screenshot of the logs. Anyways I am trying schedule this job on no server activity period and see if my df is craving for memory

Thanks

[Former Member]

There are 2 features we're talking about here

1 - run as a separate process - using this option spawns a separate process (al_engine) which performs the flattening (or whatever it is turned on for). The separate process has its own memory and threads and communicates with the dataflow al_engine. It was added back in the 32 bit days when the OS 2GB "limit" was easily reached as each process can address up to 2GB. With 64bit Data Services, the 2GB limit is not an issue (if you have enough server memory).

2 - Dataflow cache - if your dataflow needs more memory than the server has, you can use this option of a dataflow to use disk as memory, its called the Pcache.

These are totally separate settings.

[Former Member]

Hi Mike,

I understand that they are two totally different process. The fact i am trying to stress is only for flatenning transforms.

Look at this log

Run as separate process flag is set to YES for the Hierarchy_flattening transform <Hierarchy_Flattening> in data flow

<XXXXXXXXX>. This is because the dataflow is set to run in Pageable cache and Hierarchy flattening cannot

run in pageable mode. To avoid running as separate process, set data flow cache type to in_memory_cache.

Sub data flow <XXXXXX_1_1> using IN MEMORY Cache.

Sub data flow <XXXXXX_1_2> using IN MEMORY Cache.

If you see this. I had removed the run as separate process on the hierarchy flatenning and set the cache type to pageable. But if you see it defaults the run as separate process to YES if it runs in pageable and it creates sub processes. So if i want it to run with only one thread it would have to cache type to in memory. Hope i made sense here.

Thanks