Bug 478245

Summary: MIGRATED_FROM_JIRA: Control Paging added twice
Product: [Retired] penrose Reporter: Chandrasekar Kannan <ckannan>
Component: EngineAssignee: Endi Sukma Dewata <edewata>
Status: CLOSED EOL QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: benl, nmalki, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 19:46:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 471500    

Description Chandrasekar Kannan 2008-12-27 08:11:46 UTC
Jim,

With a help of another engineer who used previous version of Penrose server (1.1), I think I have found what seems to be a bug in Penrose 1.2 code base which is the cause of the problem I am having.

Here is what is happening:

Search request goes to the VDS1.  It adds a control for paging results.
VDS1 sends the search request to VDS2 and it also adds the control for paging results.
So you get a exception because the control for paging has been added twice.

The bug is in the LDAPClient.java code for penrose 1.2.  

According to him Penrose 1.1 doesn't use paging so this bug doesn't exist.

I would like to file a bug report for this and find out how soon Identyx could provide a patch for it? Please see the attached log and configuration files from both servers (our mail server strips tar attachments so I renamed them to *.rat files - you will have to rename them back to *.tar files before extracting logs and xml files)

In the meantime I discovered another problem with Penrose 1.2. It seems like the client connection to VDS times out after a while (this happens with a java client, JXEplorer LDAP browser and Penrose studio)  when the same connection going directly to LDAP server stays open without any problems. I checked the documentation and the only timeout related configuration I found is connection pool timeout which by default doesn't timeout.

If I connect to the VDS with a query and then let the client sit idle for 5-10 minutes and then make another query, the Penrose server generates the following error:

01/16/2008 13:07:45] No message handler found for message:     Extended request
        Request name : '0.0.0.0'
        Request value : '/'

org.apache.mina.handler.demux.UnknownMessageTypeException: No message handler found for message:     Extended request
        Request name : '0.0.0.0'
        Request value : '/'

        at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:148)
        at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
        at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:60)
        at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:190)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
        at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243)
        at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
        at java.lang.Thread.run(Unknown Source)



Is there an explicit option which ensures that connection to VDS doesn't get stale?

Monika


Additional Comments From endisd dated Fri Jan 25 11:52:03 CST 2008 
The paging control problem has been fixed in Penrose 1.2.5 and 2.0.

Additional Comments From endisd dated Fri Jan 25 12:11:15 CST 2008 
The second problem about the stale connection has been fixed in Penrose 1.2.5 and 2.0 with a limitation: please use LDAP (MINA) service or OpenDS service as the front-end. The ApacheDS library doesn't allow proper opening and closing connections.


=========================================================
Issue dump from jira
$VAR1 = {
          'priority' => '3',
          'customFieldValues' => [],
          'project' => 'PENROSE',
          'status' => '5',
          'components' => [
                            {
                              'name' => 'Engine',
                              'id' => '10009'
                            }
                          ],
          'reporter' => 'jimyang',
          'key' => 'PENROSE-280',
          'assignee' => 'endisd',
          'summary' => 'Control Paging added twice',
          'id' => '10964',
          'updated' => '2008-01-25 12:11:15.0',
          'votes' => '0',
          'fixVersions' => [
                           {
                             'releaseDate' => '2008-04-14 00:00:00.0',
                             'sequence' => '27',
                             'name' => 'Penrose-1.2.5',
                             'released' => 'true',
                             'id' => '10124',
                             'archived' => 'false'
                           },
                           {
                             'releaseDate' => '2008-04-07 00:00:00.0',
                             'sequence' => '28',
                             'name' => 'Penrose-2.0RC1',
                             'released' => 'true',
                             'id' => '10093',
                             'archived' => 'false'
                           }
                         ],
          'affectsVersions' => [
                               {
                                 'releaseDate' => '2007-05-18 00:00:00.0',
                                 'sequence' => '22',
                                 'name' => 'Penrose-1.2',
                                 'released' => 'true',
                                 'id' => '10088',
                                 'archived' => 'false'
                               },
                               {
                                 'releaseDate' => '2007-05-31 00:00:00.0',
                                 'sequence' => '23',
                                 'name' => 'Penrose-1.2.1',
                                 'released' => 'true',
                                 'id' => '10100',
                                 'archived' => 'false'
                               },
                               {
                                 'releaseDate' => '2007-06-18 00:00:00.0',
                                 'sequence' => '24',
                                 'name' => 'Penrose-1.2.2',
                                 'released' => 'true',
                                 'id' => '10101',
                                 'archived' => 'false'
                               },
                               {
                                 'releaseDate' => '2007-07-02 00:00:00.0',
                                 'sequence' => '25',
                                 'name' => ' Penrose-1.2.3',
                                 'released' => 'true',
                                 'id' => '10122',
                                 'archived' => 'false'
                               },
                               {
                                 'releaseDate' => '2007-07-17 00:00:00.0',
                                 'sequence' => '26',
                                 'name' => 'Penrose-1.2.4',
                                 'released' => 'true',
                                 'id' => '10123',
                                 'archived' => 'false'
                               }
                             ],
          'description' => 'Jim,

With a help of another engineer who used previous version of Penrose server (1.1), I think I have found what seems to be a bug in Penrose 1.2 code base which is the cause of the problem I am having.

Here is what is happening:

Search request goes to the VDS1.  It adds a control for paging results.
VDS1 sends the search request to VDS2 and it also adds the control for paging results.
So you get a exception because the control for paging has been added twice.

The bug is in the LDAPClient.java code for penrose 1.2.  

According to him Penrose 1.1 doesn't use paging so this bug doesn't exist.

I would like to file a bug report for this and find out how soon Identyx could provide a patch for it? Please see the attached log and configuration files from both servers (our mail server strips tar attachments so I renamed them to *.rat files - you will have to rename them back to *.tar files before extracting logs and xml files)

In the meantime I discovered another problem with Penrose 1.2. It seems like the client connection to VDS times out after a while (this happens with a java client, JXEplorer LDAP browser and Penrose studio)  when the same connection going directly to LDAP server stays open without any problems. I checked the documentation and the only timeout related configuration I found is connection pool timeout which by default doesn't timeout.

If I connect to the VDS with a query and then let the client sit idle for 5-10 minutes and then make another query, the Penrose server generates the following error:

01/16/2008 13:07:45] No message handler found for message:     Extended request
        Request name : '0.0.0.0'
        Request value : '/'

org.apache.mina.handler.demux.UnknownMessageTypeException: No message handler found for message:     Extended request
        Request name : '0.0.0.0'
        Request value : '/'

        at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:148)
        at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
        at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:60)
        at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:190)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
        at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243)
        at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
        at java.lang.Thread.run(Unknown Source)



Is there an explicit option which ensures that connection to VDS doesn't get stale?

Monika

',
          'created' => '2008-01-16 15:30:12.0',
          'resolution' => '1',
          'type' => '1'
        };


=========================================================

Comment 1 Chandrasekar Kannan 2008-12-27 08:11:50 UTC
Marking bug as MODIFIED as it was already resolved in Jira - PENROSE-280