You are not logged in.

Palo 2.5 crashes

Dear visitor, welcome to Palo Community Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

1

Friday, March 27th 2009, 11:30pm

Palo 2.5 crashes

Hi, I had several crashes on a database which previously worked...

The PaloXlAddin.log shows always a different error which does not make it easier to find the problem:

Quoted


------------------------------------------------
Freitag, 27. März 2009 21:31
Error
Error getting dimensions elements!

Exception Data:
Jedox.Palo.Comm.PaloException: Error -31 has occured (Error -31)
at Jedox.Palo.Comm.Connection.Ping()
at Jedox.Palo.XlAddin.Forms.Modeller.showElements(Connection c, String db, String dim, Boolean tree, TreeControl& treeCtrl)
------------------------------------------------
Freitag, 27. März 2009 22:36
Error
Commiting changes failed!

Exception Data:
System.NullReferenceException: Object reference not set to an instance of an object.
at Jedox.Palo.XlAddin.Connect.OnBeginShutdown(Array& custom)
------------------------------------------------
Freitag, 27. März 2009 22:36
Error
Error Setting Excel Statusbar.

Exception Data:
System.Runtime.InteropServices.COMException (0x800AC472): Exception from HRESULT: 0x800AC472
at Microsoft.Office.Interop.Excel._Application.set_StatusBar(Object RHS)
at Jedox.Palo.XlAddin.Connect.OnBeginShutdown(Array& custom)
------------------------------------------------
Freitag, 27. März 2009 23:14
Error
Error reading global subset value

Exception Data:
Jedox.Palo.Comm.PaloException: connection refused (Error -31)
at Jedox.Palo.Comm.Connection.GetData(String& str_result, Double& dbl_result, String database, String cube, String[] coordinates)
at Jedox.Palo.XlAddin.Utils.SubsetUtils.GetGlobalSubsetList(Connection c, String dbName, String dimensionName)
------------------------------------------------


I did not change anything on the database itself (except of inputs) so I have no idea what the problem is.

The PaloServer.log file shows only the error message:

Quoted

2009-03-28 13:33:25 WARNING: error code: 1015 description: invalid session message: wrong session identifier


What is the problem here???

This post has been edited 1 times, last edit by "lawa" (Mar 28th 2009, 1:49pm)

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

2

Monday, March 30th 2009, 9:16am

Which component crashes, the Addin (Excel) or the Server?

Can you link the crashes to any specific actions ("if I do xyz, the crash happens")?

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

3

Monday, March 30th 2009, 11:34am

The crash happens only with one specific database and only if I try to create a new view with the Excel AddIn. If I use an existing Excel file which already has a view on the database it shows the values correctly. I have also checked this with several server versions and it is alsways the same: The Palo Services stops, there is on XP no answer from the system - Vista (ultimate) gives the message that the Palo.exe doesn't react.

The PaloServer.log has only the shown error message.

This post has been edited 1 times, last edit by "lawa" (Mar 30th 2009, 11:35am)

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

4

Monday, March 30th 2009, 11:39am

The error message most probably isn't hte cause of this, session timeouts happen all the time and are no big deal.

What you might try is setting the verbose level in palo.ini from "info" to "trace" (restart Palo afterwards) to see if this yields any further info.

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

5

Monday, March 30th 2009, 4:21pm

I've done so. There is no entry in the PALOXLAddin.log but the Paloserver.log shows now the following:

Quoted

2009-03-30 16:04:22 TRACE: started getCellValues
2009-03-30 16:04:22 DEBUG: moving dimension Kalender to fixed list
2009-03-30 16:04:22 DEBUG: moving dimension Wert to fixed list
2009-03-30 16:04:22 DEBUG: hash area size 372
2009-03-30 16:04:22 DEBUG: starting to optimize ['Anfangsbestand','01.01.2009'] = N:STET()
2009-03-30 16:04:22 DEBUG: checking for STET rule STET()
2009-03-30 16:04:22 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:04:22 DEBUG: checking for linearity STET()
2009-03-30 16:04:22 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:04:22 DEBUG: starting to optimize ['Endbestand'] = N: ['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:04:22 DEBUG: checking for STET rule ['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:04:22 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:04:22 DEBUG: checking for linearity ['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:04:22 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:04:22 DEBUG: starting to optimize ['Anfangsbestand'] = N: PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:04:22 DEBUG: checking for STET rule PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:04:22 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:04:22 DEBUG: checking for linearity PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:04:22 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:04:22 DEBUG: starting to optimize ['Anfangsbestand'] = C: PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',1),!'Bank',"Anfangsbestand")
2009-03-30 16:04:22 DEBUG: checking for STET rule PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',1),!'Bank',"Anfangsbestand")
2009-03-30 16:04:22 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:04:22 DEBUG: starting to optimize ['Endbestand'] = C: PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',PALO.ECHILDCOUNT("Bank","Kalender",!'kalender')),!'Bank',"Endbestand")
2009-03-30 16:04:22 DEBUG: checking for STET rule PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',PALO.ECHILDCOUNT("Bank","Kalender",!'kalender')),!'Bank',"Endbestand")
2009-03-30 16:04:22 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:04:22 TRACE: finished getCellValues
2009-03-30 16:04:31 TRACE: started getCellValues
2009-03-30 16:04:31 DEBUG: moving dimension Kalender to fixed list
2009-03-30 16:04:31 DEBUG: moving dimension Wert to fixed list
2009-03-30 16:04:31 DEBUG: hash area size 372
2009-03-30 16:04:31 TRACE: finished getCellValues
2009-03-30 16:04:55 DEBUG: checking locks
2009-03-30 16:05:08 TRACE: started getCellValues
2009-03-30 16:05:08 DEBUG: moving dimension Bank to fixed list
2009-03-30 16:05:08 DEBUG: moving dimension Wert to fixed list
2009-03-30 16:05:08 DEBUG: moving dimension Kalender to fixed list
2009-03-30 16:05:08 DEBUG: hash area size 13140


after the last entry palo stopped again...

For understanding the rules:
This is used for daily cash management.
01.01.2009 is the startig date of the database so open value [Anfangsbestand] is input (=stet).
Then it looks day by day (basic elements): closing value (Endbestand) day 1 = opening value (Anfangsbestand) for day 2.
Consolidated elements are weeks and months, opening value for the week is the first child of the week; closing value = last child and so on.

The order of the elements is:
1. all days (N) in ascending order (so each day has an EPREV except of 01.01.2009 which is [stet])
2. all weeks (C)
3. all months (C)

(the consolidated elements and the basic elements in there are also in ascending order)

I don't think that there is a problem in the rules.

This post has been edited 1 times, last edit by "lawa" (Mar 30th 2009, 4:24pm)

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

6

Monday, March 30th 2009, 4:38pm

Still, you might try disabling all rules (can be done in the Rule editor) to see if the crashes still happen; if not, re-enable the rules one-by-one to see which might cause the issue.

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

7

Monday, March 30th 2009, 4:39pm

And I tried it a second time:

Now Palo stopps after that:

Quoted

2009-03-30 16:26:17 INFO: starting to listen
2009-03-30 16:28:06 DEBUG: checking locks
2009-03-30 16:29:56 DEBUG: checking locks
2009-03-30 16:31:37 INFO: got new client connection on 1716
2009-03-30 16:31:37 WARNING: error code: 1015 description: invalid session message: wrong session identifier
2009-03-30 16:31:37 INFO: user 'admin' logged in
2009-03-30 16:31:37 DEBUG: session key 3764159
2009-03-30 16:31:37 TRACE: started getCellValues
2009-03-30 16:31:37 DEBUG: moving dimension Bank to fixed list
2009-03-30 16:31:37 DEBUG: moving dimension Wert to fixed list
2009-03-30 16:31:37 DEBUG: moving dimension Kalender to fixed list
2009-03-30 16:31:37 DEBUG: hash area size 13140
2009-03-30 16:31:37 DEBUG: starting to optimize ['Anfangsbestand','01.01.2009'] = N: STET()
2009-03-30 16:31:37 DEBUG: checking for STET rule STET()
2009-03-30 16:31:37 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:31:37 DEBUG: checking for linearity STET()
2009-03-30 16:31:37 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:31:37 DEBUG: starting to optimize ['Endbestand'] = N:['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:31:37 DEBUG: checking for STET rule ['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:31:37 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:31:37 DEBUG: checking for linearity ['Anfangsbestand'] + ['Zugang'] - ['Abgang']
2009-03-30 16:31:37 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:31:37 DEBUG: starting to optimize ['Anfangsbestand'] = N: PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:31:37 DEBUG: checking for STET rule PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:31:37 DEBUG: no IF clause, stopping STET rule check
2009-03-30 16:31:37 DEBUG: checking for linearity PALO.DATA("Bank","Cash",PALO.EPREV("Bank","Kalender",!'Kalender'),!'Bank',"Endbestand")
2009-03-30 16:31:37 DEBUG: linearity works only for '*' or '/', stopping linearity check
2009-03-30 16:31:37 DEBUG: starting to optimize ['Anfangsbestand'] = C: PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',1),!'Bank',"Anfangsbestand")
2009-03-30 16:31:37 DEBUG: checking for STET rule PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',1),!'Bank',"Anfangsbestand")
2009-03-30 16:31:37 DEBUG: no IF clause, stopping STET rule check

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

8

Monday, March 30th 2009, 5:27pm

Acc. to your suggested test, the both rules
['Anfangsbestand'] = C: PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',1),!'Bank',"Anfangsbestand")

['Endbestand'] = C: PALO.DATA("Bank","Cash",PALO.ECHILD("Bank","Kalender",!'Kalender',PALO.ECHILDCOUNT("Bank","Kalender",!'Kalender')),!'Bank',"Endbestand")

cause the crash.

Well, I do not see a mistake in there and I am pretty sure that it worked when I've set this up.
However, perhaps you or somebody else see a problem there?

And, shouldn't Palo give an error message if the rule is wrong instead of crashing?

This post has been edited 1 times, last edit by "lawa" (Mar 30th 2009, 5:27pm)

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

9

Monday, March 30th 2009, 6:00pm

It may not be a syntax error in the rules. We fixed a bug that seems a bit similar to this for 3.0. In the meantime, you might try these workarounds:

- disable the server-side cache: add an entry

Source code

 
1

cache-size 0
to your palo.ini

- put markers on the rules; I'm not a marker expert, but i think replacing the PALO.DATA with PALO.MARKER in this case would suffice. Check the manual for more details on markers.

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

10

Tuesday, March 31st 2009, 10:07am

...well, I am afraid we don't find a solution but many thanks anyway.

Setting the cache size to zero gives the result that the palo-server does not crash with Palo 2.5 under XP - but the formulas are not calculated in anyway. I have tested the same database under the Palo-Beta 3.0 and with Vista and there I have seen no change- Palo Server crashes also.

Working with Palo.Marker will not work because the formula would only allow constant or variable.

After switching several rules on and of, it looks like that palo has a problem with the included PALO.EPREV lookup and with the PALO.ECHILDCOUNT. Both formulas lead to the error independent from each other.

I will try to set it up again, may be I will find a different way to do so...

Michel

Sage

  • "Michel" is male

Posts: 154

Date of registration: Jun 1st 2007

Location: Netherlands

  • Send private message

11

Tuesday, March 31st 2009, 11:04am

Hi,

I notice that your problem rule is cacluating at C: level. Can the 'Kalender' element be on a base level in a C: rule (f.i. because the Bank element is at a C: level) and thus have no children?
If so, is there a (preceding) rule that catches this 'exception'? I'm not sure what the behaviour is when you apply the ECHILD/ECHILDCOUNT construct on a base level element.

Michel

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

12

Tuesday, March 31st 2009, 11:32am

Quoted

Originally posted by lawa
...well, I am afraid we don't find a solution but many thanks anyway.

Setting the cache size to zero gives the result that the palo-server does not crash with Palo 2.5 under XP - but the formulas are not calculated in anyway. I have tested the same database under the Palo-Beta 3.0 and with Vista and there I have seen no change- Palo Server crashes also.

Working with Palo.Marker will not work because the formula would only allow constant or variable.

After switching several rules on and of, it looks like that palo has a problem with the included PALO.EPREV lookup and with the PALO.ECHILDCOUNT. Both formulas lead to the error independent from each other.

I will try to set it up again, may be I will find a different way to do so...


The fix for the bug I mentioned wasn't yet included in the Public Beta of Palo 3.
You're saying the rules aren't calculated if you disable the cache; how does this show? Do you get the original (non-rule) values / zeroes or errors?

dominik_l

Jedox Team

  • "dominik_l" is male

Posts: 348

Date of registration: May 7th 2008

Location: Freiburg / Germany

  • Send private message

13

Tuesday, March 31st 2009, 12:47pm

To add, I've tried to reproduce your issue with a similar rule on the Demo Database:

['2010'] = C: PALO.DATA("Demo","Sales",PALO.ECHILD("Demo","Products",!'Products',1),!'Regions',!'Months',!'Years',!'Datatypes',!'Measures')

While thise rule crashed the latest Palo 2.5 Version when using it in a View, the current testing version of Palo 3 does not crash with this rule. So you might also try this again with the Palo 3.0 final release (should be out in the early days of April).

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

14

Tuesday, March 31st 2009, 3:31pm

Quoted

You're saying the rules aren't calculated if you disable the cache; how does this show? Do you get the original (non-rule) values / zeroes or errors?

I get only #NV and also don't see the input values --> I guess the local server is down even if the symbol in the task bar is not red but I always need to restart again...

Quoted

I'm not sure what the behaviour is when you apply the ECHILD/ECHILDCOUNT construct on a base level element.


I'll try to explain what I want with the Kalender element:
(please see attached picture)

Kalender includes all days (base level), weeks, months, year (all C level).

[Endbestand]=[Anfangsbestand]+[Zugang]-[Abgang]

[Anfangsbestand]today = [Endbestand]yesterday

[Anfangsbestand]week 9 = [Anfangsbestand] 22.02.2009 (first element in hierarchy)

[Endbestand]week 9 = [Endbestand] 28.02.2009 (last element in hierarchy)

Same with months and years...
lawa has attached the following image:
  • palo.png

Michel

Sage

  • "Michel" is male

Posts: 154

Date of registration: Jun 1st 2007

Location: Netherlands

  • Send private message

15

Tuesday, March 31st 2009, 4:49pm

Hi,

I understand what you're trying to establish. The thing I noted is that the rule could hit a base-level Kalender element (f.i. 22.02.2009) in the C: rule in case the Bank element is consolidated (in this case the cell is consolidated, but the Kalender element is base-level).
In this case the rule tries to find the last child of a base-level element. I'm not sure (never tested this) what the result of this will be - could it be the cause of you're problems?
Maybe adding an IF statement to the rule checking whether Kalender is not at base-level will help?

Michel

lawa

Master

  • "lawa" is male
  • "lawa" started this thread

Posts: 41

Date of registration: Jan 28th 2009

Location: Dresden

  • Send private message

16

Tuesday, March 31st 2009, 11:31pm

Well, I guess I will give it up now.

I have changed the different C and N rules to one rule which checks the elevel of the Kalender-Element with if-clause - nothing changed.
(The Palo.Eprev part still must remain and this can be the only remaining problem.)

I tried JPalo (to be sure it has nothing to do with the Excel AddIn):
Jpalo says only "invalid path" and Palo.exe crashes again.

I am pretty sure that my rules are correct - at least they are according to the rule editor and the palo manual.

If somebody is still interested in this odd case, I would send the database directly.

However, thanks a lot for your time and your ideas...

Regards
Rate this thread