Bug 478245 - MIGRATED_FROM_JIRA: Control Paging added twice
MIGRATED_FROM_JIRA: Control Paging added twice
Status: MODIFIED
Product: penrose
Classification: Retired
Component: Engine (Show other bugs)
2.0
All Linux
low Severity low
: ---
: ---
Assigned To: Endi Sukma Dewata
Ben Levenson
:
Depends On:
Blocks: 471500
  Show dependency treegraph
 
Reported: 2008-12-27 03:11 EST by Chandrasekar Kannan
Modified: 2016-01-28 17:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chandrasekar Kannan 2008-12-27 03:11:46 EST
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 03:11:50 EST
Marking bug as MODIFIED as it was already resolved in Jira - PENROSE-280

Note You need to log in before you can comment on or make changes to this bug.